m2 and aspectj
Hey! Are there any official plans to create an aspectj plugin for m2? What's special and not clear for me about aspectj is: - there can be jars which contain aspects - do we need another types/scopes for them distinguishing them from ordinary jars? if yes what values of those attributes should be actually used and how new types/scopes can be registered. - aspects can be applied at the build time and what's going to be officially supported in aspectj 5 at the runtime (load-time weaving). How to distinguish those two case at the level of dependencies? Can build time and load-time weaving be used for the same application - e.g. some aspects applied at the build time some at the runtime? Just to have something more concrete - my particular use case is: I have an existing web application (war). I want to weave some aspects into some jars (not all of them) which are used in that application. I have really no clue how it can be done in a proper way in m2. Is there anything done already to enabled this or a general vision how this use case can be implemented in a correct way? Any pointers where to start? regards Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
My resignation
Hereby I want to announce my resignation from Maven PMC and the retirement from the function of Maven Committer (this is including every project developed under maven umbrella). I just feel that I am no longer able to be a valuable part of the Maven team. There are two things which I recently started and which are not yet finished: - upload/download cancellation in wagon (I need it badly for one of my projects) - improved site navigation in m1 First thing was not committed to cvs and therefore there should not be any problem if I will implement it else where outiside the apache. For the second thing: I leave you the choice how you (it's probably up to Brett) want to handle it and if you want to continue in that direction. If you want me to revert this change in SVN just let me know. Thank you guys for all those things I learnt from you during all those years! Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: copy depency artifact to a certain place
other option might be to do this in the similar way as war plugins does. Which means you can add annotation to a dependency with help of tag Michal > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Sent: Friday, February 18, 2005 11:34 AM > To: Maven Users List > Subject: Re: copy depency artifact to a certain place > > > Thanks Mario, >I already did that :) >I was just wondering if there is a more elegant way to > fullfill the > task. > > > 10x again, > Kaloyan > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: How to configure the name of the target directory?
> -Original Message- > From: Gisbert Amm [mailto:[EMAIL PROTECTED] > Sent: Thursday, February 17, 2005 11:36 AM > To: Maven Users List > Subject: Re: How to configure the name of the target directory? > > > Yes, maven.build.dir is exactly what I was looking for. Sorry for > bothering you with a RTFM question. I had somehow overseen it > (not yet > fully waken up, I suppose ;-) > > Thanks, > Gisbert > >Hey I think it won't be that wise to change it. I bet it is so commonly used now that some plugins may have hardcoded paths which are using target directory. Is there any particular and good reason why you want to change it? Isn't it better to use what everybody else is using? Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: How to use site:ftpdeploy
you want to use site:deploy goal and set "maven.site.deploy.method" to the correct value michal > -Original Message- > From: Laurent Michenaud [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 02, 2005 1:03 PM > To: users@maven.apache.org > Subject: How to use site:ftpdeploy > > > i'm trying to use the goal site:ftpdeploy but nothing is deployed and > it prints SUCCESSFUL. > > build:start: > > xdoc:init: > > site:init: > > site:ftpdeploy: > [echo] > siteAddress = 192.168.1.6 > siteDirectory = /var/www/monprojet > siteUser = bertrand > > BUILD SUCCESSFUL > Total time: 4 seconds > Finished at: Wed Feb 02 13:00:34 CET 2005 > > > - > 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: war plugin: including Tomat context.xml in META-INF?
> -Original Message- > From: Michael Schuerig [mailto:[EMAIL PROTECTED] > Sent: Friday, January 21, 2005 1:50 PM > To: users@maven.apache.org > Subject: war plugin: including Tomat context.xml in META-INF? > > > > Tomcat allows to define JNDI resources in the file > META-INF/context.xml > include in the web app's war. I don't see how to put a file > there using > the war plugin. Is it possible? > put this file into (the recommended location) src main resources META-INF and use section in your POM to declare this location. Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Dependencies in dependant POMS
> -Original Message- > From: Stevenson, Chris [mailto:[EMAIL PROTECTED] > Sent: Friday, January 21, 2005 11:48 AM > To: 'users@maven.apache.org' > Subject: Dependencies in dependant POMS > > > Hello All, > > I know this question has probably been asked before but I > can't find any > info on it in the archive. It is simple one. If I reference a business > object artifact from a webservice POM and the Business Object > POM has a list > of extra dependencies that are not directly required by the > Web Service (For > example the JDBC Driver JAR) will Maven download those indirect > dependencies? > > Thanks, > > Chris > This concept is called transitive dependecies and is not yet supported by any released version of maven. You will have to wait for it (it is already implemented and scheduled for maven2 alpha release) . Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Reactor: Error getting projects
> -Original Message-
> From: Roberto Castro [mailto:[EMAIL PROTECTED]
> Sent: Thursday, January 20, 2005 3:04 PM
> To: users@maven.apache.org
> Subject: Reactor: Error getting projects
>
>
> Hi all, reactor is facing a problem when it tries to find
> subprojects "project.xml" files, when I run
> multiproject:deploy. All subprojects are in directories like
> these: "SILOC/SilocLog", "SILOC/SilocException". I configured
> "maven.multiproject.basedir=${basedir}/SILOC" and
> "maven.multiproject.includes="SilocLog/project.xml,SilocExcept
> ion/project.xml" but reactor is not able to find subprojects.
> Here is the error:
> BUILD FAILED
> File..
> /home/gver/.maven/cache/maven-multiproject-plugin-1.3.1/plugin.jelly
> Element... maven:reactor
> Line.. 63
> Column 9
> Error reading XML or initializing
> com.werken.werkz.UnattainableGoalException: Unable to obtain
> goal [goaldefault] --
>
> /home/gver/.maven/cache/maven-multiproject-plugin-1.3.1/plugin
> .jelly:63:9: :reactor> Error getting projects
> at com.werken.werkz.Goal.fire(Goal.java:646)
> at com.werken.werkz.Goal.attain(Goal.java:575)
> at
> org.apache.maven.plugin.PluginManager.attainGoals(PluginManage
> r.java:671)
>
> I've been using mavem 1.0.2.
> Is there anytihng I can do to solve this problem?
> Thanks a lot in advance for the help.
>
probably one of your project.xml files is not well formed.
try to play with mutiproject's includes/excludes if you have very many
projects
or to build them one by one if you have just a few of them
michal
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: repository problem.
> -Original Message- > From: rajas kumar [mailto:[EMAIL PROTECTED] > Sent: Monday, January 17, 2005 2:42 PM > To: Maven Users List > Subject: RE: repository problem. > > > yaa we are using cvs in that already all dependency jar files > are there under. > c:\\\**\lib > > for to use build script every body needs repository. For this > i need to check -in my repository.This will makes redudency. > Why i need to make redencey for this jar files. That is the problem. I don't see much of such redundancy (specially if you are using cvs). 99%of books/artciles I have ever read regarding scm and which are describing so called best pratices make it clear: Repository for the source code and repository for binary artifacts don't have the same charateristis and they need other set of features. With the software like subversion that gap is closing but it still exists. Maven is just an implementation of the idea which is exists since a long time: Artifact repository. Pretty much any advantage which maven provides in comparsion to tools like ant is enabled thanks to existsince of the concept of the repository in maven and to the fact that this repository is separted from the projects. This will enable such cool things like transtitive depenencies (dependecies of the dependecies), auditing tools, "intelligent" countinuous integration system which are for example able to try to test your projects agaist different version of given liblary and provide various benchmarks and many more things. Once it will happen the things which you are trying to do now will be looking like remainigs from the previous age :) I understand what you are trying to do - but you are acting agaist the fundmental concept of maven and this might be a painful way for you to go and you will loose access to most of the profits which you gain when you are using maven in standart way... Note that you can also maintain maven repository in cvs thanks to tools like cvsview Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: repository problem.
> -Original Message- > From: rajas kumar [mailto:[EMAIL PROTECTED] > Sent: Monday, January 17, 2005 1:37 PM > To: users@maven.apache.org > Subject: repository problem. > > > Hai, > > I have several dependencies jar files are needed for to > compile.All these jar files are in mycvs under lib folder such as > > lib--!-apache---somejar files > !-jsf--some jar file > !-common-some jar files > > > like this my lib directory structure > >I have made repository like apache--jars---jarfile > jsf ---jars --jarfile > > > i have given dependency like > > apache > > commons-beanutils > > commons-beanutils.jar > > present its working fine. > > But issue is i dont want to create repository. How can i make > this automatic and how can i give this dependency. Is it > possible to use that jars files as dependency directly. > Do you have any valid reason why you don't want to make it in the normal way which is supported by maven? Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven project for a running environment?
> -Original Message- > From: Tom Bostelmann [mailto:[EMAIL PROTECTED] > Sent: Monday, January 10, 2005 10:10 PM > To: Maven Users List > Subject: Maven project for a running environment? > > > Is anyone using Maven to create a running environment like, for > instance, CATALINA_BASE? > > > > I was wondering if it's possible to have a project that > creates a Tomcat > running environment that might look like: > > > > conf/ > > logs/ > > shared/lib/ > > temp/ > > webapps/ > > > > Then, I'd like to have dependencies for that project be other > 'war'-type > projects. I would create a maven goal that would iterate through the > dependencies and put the artifacts in their respective places. > > > > Is it possible? Is it a bad idea? > Tom if you wish I can send you my plugins which does exactly that. It is limited to tomcat at the momemt and I haven't used it for months but I hope it will be still working. I believe that this pattern can be generalize and single plugin can be used for creating most of the runtime env. The idea is that you need merge artifacts deployed to the repository and specified in pom into the single artifact. What does it mean "to merge" may vary but it can be easly cotrolled per artifact type. You are free to select which artifact you need (e.g. if you need scripts for both windows and unix) and easly provide your own replecment for some defult artifacts (e.g. your customized scripts). In any of those cases you just need to create appropiate zips (e.g. tomcat-base.zip tomcat-windows-scrips.zip and tomcat-unix-scripts.zip) and list wars which you want to use (you are not required to ship you runtime with manager and admin webapps). Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: javadoc-plugin problem
add tag to your pom
michal
> -Original Message-
> From: Jeroen Heijmans [mailto:[EMAIL PROTECTED]
> Sent: Friday, December 17, 2004 10:24 AM
> To: [EMAIL PROTECTED]
> Subject: javadoc-plugin problem
>
>
> Hi,
>
> I'm having the following problem with the javadoc-plugin. If I run
> "maven javadoc", it complains:
>
> [echo] ***
> [echo] * No sources found. Javadoc not created ! *
> [echo] ***
>
> and when I run the site goal (with the maven-javadoc-plugin in the
> reports), it doesn't do anything, not even display the
> message given by
> the javadoc target.
>
> However, my project does have sources, and they are also found by all
> other goals I run with maven. I then tried running it again with
> maven.javadoc.debug set in my project.properties, but I got
> no alarming
> information. maven.compile.src.set points to
> ${basedir}\src\java, which
> is indeed where my source files are.
>
> I was initially using the 1.6.1 version of the javadoc-plugin, but an
> upgrade to version 1.7 (including the latest required libs) gave no
> improvements. I have nothing set in my properties file (save
> maven.javadoc.debug), and I've tried changing all parameters in the
> project.xml that might have anything to do with this, but
> none of them
> made any difference. I'm running Maven 1.0 on Windows XP.
>
> Any help would be greatly appreciated,
>
> Jeroen Heijmans
>
>
>
>
>
>
>
> -
> 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: changing version of module and dependent modules
> -Original Message- > From: Jörg Schaible [mailto:[EMAIL PROTECTED] > Sent: Friday, December 17, 2004 9:07 AM > To: Maven Users List > Subject: RE: changing version of module and dependent modules > > > Maczka Michal wrote on Thursday, December 16, 2004 1:58 PM: > > > I've trying to find a nice solution for that issue since a > > long time (sometimes I have up to 40 projects using the same > > artifacts!). I come into the conclusion that any way of using > > version pointers in poms (e.g. xml entities or jar > > overriding) is bad thing as it might be against the > > repreductability of builds (unless modified poms with > > "inlined" information are deployed to the repository, but > > this creates other problems!!) > > Only thing which can really solve that complexivity is a tool > > (GUI), which will help to make a quick migration to the given > > version of the given artifact for group of projects. My > > colleagues from work have developed the maven plugin which > > helps to do this migration - it is already quite useful for > > them, but not fully operational and it requires other our > > plugins therefore it will be useless for somebody else, but > > it is not hard to write your own plugin with similar > functionality... > > Sorry, but I really want to know, how to do this in a company > with a lot of multiprojects. We're using entities heavily and > keep all our project in this way in sync (yes, all the > project share the same entity definitions, although the > versions can be overridden locally and individually). Nobody > has all projects checked out. In such a scenario neither a > GUI tool nor a plugin does help. > I am pretty sure GUI will help here. One of things which is possible with maven is a database of all your projects. Together with continuus integration system it will enable a lot of really cool and fascinating things. For example once you will make a point release of a module - continous integration system can build and test all modules which were using older version of that module agaist this new release. You will be able to see a report which of them worked, what was the impact on performance and for example recieve a proposition to upgrade some/all of them to this new version. You won't be required to directly work with scm systems or even touch xml files or files with entities. This is of course just hypotetical scenario - but I am pretty sure that the level abstraction of project, xml files, entities is too low to deal with such complex problems. We really need tools which will aggregate that rich knowlege which sits in poms to do interesting things and save hours of our time! > How do we ensure reproducability? The entities are also kept > in a CVS repository and every time a project is tagged, the > repo with the entities is tagged also. > > If you really drop entitity support completely, this will be > a desaster for our company. > We understand that problem. If we will deprecate entities or stop supporting them we will need to propose working replacement. At the moment jar overriding facility is the only alternative which we have. Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: changing version of module and dependent modules
> -Original Message- > From: Marcin Gurbisz [mailto:[EMAIL PROTECTED] > Sent: Thursday, December 16, 2004 12:56 PM > To: Maven Users List > Subject: changing version of module and dependent modules > > > I would like to have possibility to change version of > specific library > in all project.xml files all over the project.. > To make it clearer I give an example: > Module A and B depends on C, and I want to change version of C. After > executing some goal I would expect that version of module C and all > dependent would change. > Have anyone solved this problem or you are dealing with it in > diferent way? > I've looked at release plug-in and it seems to me that it change only > version in "C" module. Am I right? > I've been using xml entities to ensure project consistency so this > problem hasn't occurred but I want to get rid of entities. > > I've trying to find a nice solution for that issue since a long time (sometimes I have up to 40 projects using the same artifacts!). I come into the conclusion that any way of using version pointers in poms (e.g. xml entities or jar overriding) is bad thing as it might be against the repreductability of builds (unless modified poms with "inlined" information are deployed to the repository, but this creates other problems!!) Only thing which can really solve that complexivity is a tool (GUI), which will help to make a quick migration to the given version of the given artifact for group of projects. My colleagues from work have developed the maven plugin which helps to do this migration - it is already quite useful for them, but not fully operational and it requires other our plugins therefore it will be useless for somebody else, but it is not hard to write your own plugin with similar functionality... pozdrawiam Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Problems with JavaCC plugin
> -Original Message- > From: M.-Leander Reimer [mailto:[EMAIL PROTECTED] > Sent: Thursday, December 16, 2004 11:27 AM > To: Maven Users List > Subject: Problems with JavaCC plugin > > > Hi, > > I have the following comments and problems with the JavaCC plugin: > > - Bug: I want to generate my parser files into the following package > structure: de.adaptions.emp.webcontainer.util > Everything generates fine, but when it comes to compiling the > generated > sources, I get an error like > > illegal unicode escape > /* Generated By:JJTree: ... > webapp\target\generated-src\main\java\de\adaptions\emp\webcont > ainer\util > \parser\TextFormatParserTreeConstants.java */ > A! I forgot to add tha it seems to be a bug in javacc as it with deafult settings generates a java class which cannot be compiled by javac parser. (I will look closer at this problem in next few days so I migth be wrong) Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Problems with JavaCC plugin
> -Original Message- > From: M.-Leander Reimer [mailto:[EMAIL PROTECTED] > Sent: Thursday, December 16, 2004 11:27 AM > To: Maven Users List > Subject: Problems with JavaCC plugin > > > Hi, > > I have the following comments and problems with the JavaCC plugin: > > - Bug: I want to generate my parser files into the following package > structure: de.adaptions.emp.webcontainer.util > Everything generates fine, but when it comes to compiling the > generated > sources, I get an error like > > illegal unicode escape > /* Generated By:JJTree: ... > webapp\target\generated-src\main\java\de\adaptions\emp\webcont > ainer\util > \parser\TextFormatParserTreeConstants.java */ > > It's the \u (the u from util) which it complains about. > > I tried setting the undocument properties (found them in the jelly > script) "maven.javacc.javacc.header" and "maven.javacc.jjtree.header" > but it doesn't have any effect on the generated sources. > > - Comment: The properties section in the plugin documentation is > incorrect or incomplete, e.g. the properties for > "maven.javacc.javacc.target.dir" and > "maven.javacc.jtree.target.dir" are > not used at all, and the header properties are missing. > > What can I do to solve problem 1? Any suggestions? Quick workaround is to generate your parser into the package which doesn't have any segment which name starts with "u"... IN you case if you can switch from de\adaptions\emp\webcontainer\util\parser to de\adaptions\emp\webcontainer\tool\parser or de\adaptions\emp\webcontainer\parser it will probably work... >Should I file Jira > issues for the problems mentioned? > yes Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Reactor & SubProject interdepencies
> -Original Message- > From: Richard Bair [mailto:[EMAIL PROTECTED] > Sent: Tuesday, December 14, 2004 7:50 PM > To: Maven Users List > Subject: Re: Reactor & SubProject interdepencies > > [aside] > Well, I was going to use multiproject, but honestly I > can't figure out what is the "best practices" way of > doing things, and what isn't. From a noobs > perspective, Maven looks really powerful but I have > almost *no* idea what the preferred way of doing > anything is. Aside from having to learn how to script > in jelly, what goes into > build.properties/project.properties/project.xml/maven.xml > or what some obscure error means (the current one is [..,] > [/aside] > > Thanks David > Rich Probably one of the reasons why such practices has not been yet clearly communicated and described is that some of those of practices were born with maven. In order to tell what good practice is or what is not you need to have a substantial experience. AFAIK no commonly used tool before maven has a support for such features like "project inheritance" and "reactor" hence nobody had real experience with them. We are still experimenting with those features, learning from our users' experience and trying to find best ways of doing things. There is a new concept coming to maven - Unified Source Directory, which will be our proposition how to structure projects in the way which will allow to have things quickly and smoothly done. It is still a work in progress, but once it's done it will be really helpful as it will be clear "how the things should be done". At the moment you may look at more complex projects like Apache Geronimo to learn how they organize their build system. We are doing the same :) ... to learn what kind of functionality people really need from maven and what is working for them and what is not. Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Multiproject --> not from top directory?
try something like:
maven.multiproject.basedir=../
maven.multiproject.exclude=moduleWhichAssemblesTheFinalApp/project.xml
Michal
> -Original Message-
> From: Aleksandr Shneyderman [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, December 14, 2004 7:28 PM
> To: [EMAIL PROTECTED]
> Subject: Multiproject --> not from top directory?
>
>
>
> I have a project that consists of multiple submodules
> All of the modules are on the same level. One module is
> the one that assembles the final app.
>
> How do I tell multiproject to look for dependent modules
> in ${basedir}/../dep-mod-A, ${basedir}/../dep-mod-B
> and so on?
>
> Thanks,
> Alex.
>
>
> -
> 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: Reactor potential bug
> -Original Message- > From: Stéphane Nicoll [mailto:[EMAIL PROTECTED] > Sent: Monday, November 08, 2004 11:27 AM > To: Maven Users List > Subject: Reactor potential bug > > > Hello list, > > I think I might have found a bug in the reactor, could you > please validate I am not missing something. > > I have a maven project inside a release process that > downloads module dependencies and rebuild a source.jar of one > of our application (for debugging purposes). We have also a > little tool that scans the files to see the differences. > Have you thought about using - version tags in POM for tracking the history of the project?? - using scm features for generating such reports. if I understand changelog report is not that far away from what you are trying to do.. maybe any of those will be helpful for you? Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: A war dependency
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 04, 2004 12:01 PM > To: [EMAIL PROTECTED] > Subject: RE: A war dependency > > > I think > > > my_war > 2.0 > war > > > is what you're after > Note that tag is also depreacted! groupId, artifactId pair of tags should be used instead. Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Project Distribution Process
> -Original Message- > From: Duncan Krebs [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 04, 2004 2:36 AM > To: Maven UserList > Subject: Project Distribution Process > > > Hi, > I've been working on implementing Maven into my build process > and was wondering how to go about a couple of things. > > When I build a distribution of a project I want Maven to put > that newly compiled jar into a central repository so that > other projects can reference to it in project.xml. Would this > newly created jar go into the same repository that holds all > my third party jars? If thats the case then I'd have to > create my own central repository and not use the public one? > If you work alone you may just stick to your local repository. If you share your work (aars) with others you may want to setup your remote repository. Note that the name "central" repository is used to refer to the repository hosted at ibiblio. There could be only one central repository - in your case the correct term is _remote_ repository. Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 19, 2004 10:49 AM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: RE: Maven > > > Hi, > > Maven creates jar, but with name "PROJECT-version.jar" eg:- > PROJECT-12.0.0.jar, > is there anyway i can override this to create "project.jar" > This is not something which you would normally want to do with maven. Jars and other artifacts are versioned for numerous good reasons. Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Dependency problens when generating war file
> -Original Message-
> From: Roberto Castro [mailto:[EMAIL PROTECTED]
> Sent: Friday, October 15, 2004 3:03 PM
> To: [EMAIL PROTECTED]
> Subject: Dependency problens when generating war file
>
>
> Hi, all. I've been facing two problens generating a war file.
> Maven inserts jar files into war files with version number in
> its name. To avoid this, I created a goal in maven.xml to
> rename jar file, like this:
> file="${maven.build.dir}/web-inf/WEB-INF/lib/commons-beanutils
> -${siloc_commons_beanutils_version}.jar"
>
> tofile="${maven.build.dir}/web-inf/WEB-INF/lib/commons-beanuti
> ls.jar" overwrite="true"/>
> Is it the better way to do this?
First question is - why do you want to do this?
This is really something which is not needed.
> Second problem:
> To copy tld and xml files into war file, I do the following:
>
> [EMAIL PROTECTED]
> src
>
>
> web/config
>
>
> *.xml
> *.tld
>
>
>
>
>
> But maven copys tld and xml files into "WEB-INF/classes"
> directory, insted of, "web-inf" directory.
> What can I do to solve this problem?
> Thank you all in advance for the help.
> Regards,
>
This is known limitation. we don't have yet a possibility of having
resources of web application (war plugin).
Resources are processed only by java plugin (test resources by test plugin).
This is indeed painful.
The simplest solution if you don't have to use resource filtering is to put
configuration files directly in the place where they
should be in the war file:
e.g. src/main/webapp/WEB-INF
Michal
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: extra files in META-INF
> -Original Message-
> From: Charles N. Harvey III [mailto:[EMAIL PROTECTED]
> Sent: Thursday, October 07, 2004 5:37 PM
> To: Maven Users List
> Subject: extra files in META-INF
>
>
> Hello.
> I am trying to use Hivemind and it requires that my config
> files get placed
> in the META-INF directory of my jar file. So far, from the
> jar plugin, I
> can't seem to figure out where I should place these files and what
> properties
> I have to set to get them built into the jar.
>
> project/
> /src/
>/main/
> /java/
> /resources/
> log4j.properties
> /descriptor/
> my-modules.xml
>
> Everything in /resources/ gets into the top level "directory" of the
> compiled
> jar. But how do I get files into project.jar/META-INF/?
> Should/can I
> put them
> in /descriptor/? Should I put them somewhere else? The only options
> that I can
> see in the jar plugin are to add extra information to the
> file that Maven
> generates.
>
> Any help is much appreciated.
>
There are two possiblities
a) you can structure it like:
resources/
log4j.properties
META-INF/
my-modules.xml
b) you can use targetPath element in defiition of your resources
${basedir}/src/resources/descriptor
META-INF
*.xml
I prefer a) as it is also supported by IDEs like IDEA or Eclipse.
Michal
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Dependency of type property
You may put such resources into jars. Michal > -Original Message- > From: Marco Tedone [mailto:[EMAIL PROTECTED] > Sent: Thursday, September 09, 2004 4:18 PM > To: Maven-users > Subject: Dependency of type property > > > Hi, is there a way to declare a dependency of type > 'property'? The reason is > that it would be usefull to have a dependency of type > property when using > Struts (and I think not only) for MessageResource bundles. Basically a > company may want to use always the same type of labels (already > internationalized) for all its sites. Instead of copying the > same every > time, it would be nice to be able to declare a dependency and > include it in > the war artifact. > > Marco > > > - > 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: dependency dependencies
> -Original Message- > From: Nathan Coast [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 08, 2004 10:25 AM > To: Maven Users > Subject: dependency dependencies > > > Hi, > > Is there any mechanism to obtain a full list of the > dependencies of dependencies in > jellyscript? I know there are reports generated e.g. > http://maven.apache.org/reference/plugins/dependency-convergen > ce-report.html > > I'm trying to access the dependencies from within jelly. Are > there api calls to do this? > > I've seen some code in > org.apache.maven.multiproject.harmonizer but I don't think it's > what I'm looking for. > AFAIK no such thing exists for maven 1 in Apache CVS but I know some people who implemented it for their own usage... If just "full list of the dependencies of dependencies" is what interest you (you are not interested in seeing a graph) we have such thing implemented for m2. You could reuse the same algorithm for m1: http://cvs.apache.org/viewcvs.cgi/maven-components/maven-artifact/src/main/j ava/org/apache/maven/artifact/resolver/DefaultArtifactResolver.java?rev=1.4& view=auto Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: List all dependencies or only main ones?
> -Original Message- > From: Stijn de Witt [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 03, 2004 12:10 PM > To: Maven Users List > Subject: List all dependencies or only main ones? > > > Hi, > > A quick question. Assume a project A, which depends on > projects B and C. If > project D depends on A, does it also have to state it's (implicit) > dependencies on B and C in project.xml? > Search in mailing list archive as this is quite frequent question. Shortly this is called "transitive dependencies" and it is not supported by any released version maven but is coming soon (we have basic implementation of this stuff in CVS) Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: artifact for jsp taglib: bug? bad practice? or what?
> -Original Message- > From: Marcin Maciukiewicz [mailto:[EMAIL PROTECTED] > Sent: Monday, August 02, 2004 10:56 AM > To: [EMAIL PROTECTED] > Subject: artifact for jsp taglib: bug? bad practice? or what? > [..]> > Question 1: Is described behaviour bug or not? It's a feature :). But this will be changed in next major release of maven (1.1 and/or 2.0) > Question 2: Is described case good practice or not? It depends. For Servlet Containers which support servlet api >= 2.3 probably the most appropriate solution is to relay on tld discovery mechanism built-in into container http://www.onjava.com/pub/a/onjava/2001/10/10/jsp.html?page=2 In case of other artifact types or if you have to use JSP 1.1 unfortunately such nice workarounds are often not existing. pozdrawiam Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: file:// protocol not working for remote repsoitory in 1.0
> -Original Message- > From: Dion Gillard [mailto:[EMAIL PROTECTED] > Sent: Wednesday, July 28, 2004 5:30 PM > To: Maven Users List > Subject: Re: file:// protocol not working for remote repsoitory in 1.0 > > > It's because it's a malformed URL and the 'host' is assumed to be C: > Possibly. But still I don't see any relation between C: or file: and ftp:// :) Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: file:// protocol not working for remote repsoitory in 1.0
> -Original Message- > From: Peter Anning [mailto:[EMAIL PROTECTED] > Sent: Wednesday, July 28, 2004 8:32 AM > To: [EMAIL PROTECTED] > Subject: file:// protocol not working for remote repsoitory in 1.0 > > > Hi all, > > We have a remote repository located on a Windows file server. > > The repository could be accessed using the file: protocol in > maven rc2 > upgrading to 1.0 seems to have broken this. I have tested it > by putting the > jar in question behind a local http server and it works. > > build.properties are set as: > maven.repo.remote=file:lonfs02/EBJAVA/repository,http://ww > w.ibiblio.org/ma > ven,http://dist.codehaus.org,http://www.codeczar.com/maven > maven.repo.remote.enabled=true > > Has anyone else seen this? > > Below is the stack trace. I have seen anything like that but what's strange is the fact that maven is trying to use ftp protocol for downloading your artifacts from that location. In addition JDK URL handler for FTP is used... and this is highly bizzare! Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Multiple dependencies of different types
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Friday, July 23, 2004 4:20 PM > To: [EMAIL PROTECTED] > Subject: Multiple dependencies of different types > > > It would seem that Maven 1.0 does not take the element > into account > when downloading a dependency. Is that correct behavior? > > I have a project that's meant to be a master build over a > number of other > projects. For example, it downloads a project A's artifact > (i.e. a jar > file) and then intends to interrogate that A's POM and subsequently > download A's dependencies. So, in the master project's > project.xml I've > listed its dependencies as: > > > A > A > 2.1.0.2 > > > > A > A > 2.1.0.2 > pom > > > > Apparently to Maven there's no difference between these two > dependency > entries even though they are in fact different things: one's > a jar file > the other is a POM file. So, Maven only reports a single > dependency for > that groupId-artifactId when, say, you iterate over the pom.artifacts > list. > This is known limitation which soon will be fixed. Your particual use case will be even built-in into maven: whenever maven will dowload any artifact it will download its pom. Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: problem using snapshots in JAR override
IMO what you are trying to do is no more no less then cheat your build managers :) If they dislike the idea of SNAPSHOT artifacts - its better not to use them or explain to them what for you need to use them. You may also consider using 2.1-SNAPSHOT 2.1-SNAPSHOT this is what will be soon a default and recommended way of doing (this allows to have snapshot per version (branch)) In m2 we have already one single install goal which is "smart" enough to check project's type and version . It means that soon you will be able to do: maven install and this will do what (depending of the context) what jar:install, jar:install-snapshot, war:install, ejb:install, ejb:install-snapshot etc goals used to do. Michal > -Original Message- > From: Marcel Vehof [mailto:[EMAIL PROTECTED] > Sent: Friday, July 23, 2004 10:45 AM > To: '[EMAIL PROTECTED]' > Subject: problem using snapshots in JAR override > > > > Hello, > > In our organization we want to use snapshot versions of > some of our libraries, during developing. > Normally, this would be done by stating the version number > for the library as SNAPSHOT in project.xml > But this practice is not allowed by our build managers, > they only want references to officially released versions > in project.xml > > So, I tried the JAR override feature and added the following > to build.properties (since this file is not in version control, > the content is no problem for the build managers) : > > maven.jar.override=on > maven.jar.mylibrary=SNAPSHOT > > This does not work as I expected, what happens is that the > snapshot dependency is downloaded, but to the home directory > of the project, with filename "Snapshot". > Also when building an EAR, the library ends up with filename > "Snapshot". Besides that this is not the correct name, it will > definitely not work if there are more than one snapshot > dependency in the project. > > Does any one know how to solve this ? > > > Marcel Vehof > > --- > This message is confidential and may be privileged. Any review, > retransmission, dissemination or other use of, or taking any > action with > reference to this information by persons other than the > intended recipient > is prohibited. If you received this message in error, please > notify the > sender by reply e-mail and delete this message from all > computers. Please > note that e-mails are susceptible to change. The sender will > not accept > liability for the improper or incomplete transmission of the > information > contained in this message. > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Reactor: tests failing (working dir set to master proj dir no t child proj dir)
> -Original Message-
> From: Ben Walding [mailto:[EMAIL PROTECTED]
> Sent: Monday, July 12, 2004 3:26 PM
> To: Maven Users List
> Subject: Re: Reactor: tests failing (working dir set to
> master proj dir
> no t child proj dir)
>
>
> Maczka Michal wrote:
>
> >
> >
> Another option is to check the basedir property ->
> System.getProperty("basedir") which is the base of the
> current project.
>
> I personally prefer the classloader approach, but it's worth knowing
> about both methods.
My point was that "basedir" property does not exist outside maven. You have
to set it manually for each test if you are using Eclipse/IDEA
Michal
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Reactor: tests failing (working dir set to master proj dir no t child proj dir)
> -Original Message- > From: Omair-Inam Abdul-Matin [mailto:[EMAIL PROTECTED] > Sent: Saturday, July 10, 2004 5:39 AM > To: [EMAIL PROTECTED] > Subject: Reactor: tests failing (working dir set to master > proj dir not > child proj dir) > > > I'm using JUnit to run some regression tests that need to read in > configuration and data files. For this it is necessary that > the working > directory be the same as the project directory. Recently the project > was subdivided into a master project and child subprojects. > Now when I > try to run unit tests by invoking the master build target, the tests > fail because apparently the working directory is the directory of the > master project not the current child project. I believe this > topic has > been brought up in a previous post but I was not able to find the > solution to the problem. > > Can someone please nudge me in the correction direction? > > Omair > > You may also conider using classloader for loading your configuration files: http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ClassLoader.html#findResou rce(java.lang.String) Once you have an URL of required resource you can easly convert it to a File object and then use methods like file.getParentFile() for traversing directories Using this technique you can more easly test your code in your IDE. Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Need to load common goals from sub-projects maven.xml
> > > No. Plugins are recommened way of doing this. > > I don't understand. Say I've got a persistence components > that requires > XDoclet to be run prior to compiling then I might do this in > my maven.xml: > > > > > > > > > > > So if I then create 2 more persistence components that need > the same thing > to happen then I might recognise a duplication and refactor > it out to a > plugin. However, would I still need to do the following in each of my > maven.xml's for my 3 components? > > > > > > If these components were running inside the reactor wouldn't > it be better to > simply put these lines in the parent project's maven.xml? > > To answer my own question, having looked at some other > plugin.jelly, it > seems that I could put the same preGoal into my plugin.jelly. > Is that what > you you were getting at? Sorry for being slow. > No! preGoals should not be used by plugins. At the moment indeed the solution which involves plugin requires very short duplicating blocks in maven.xml. Probably we will be able to eliminate the need for most of them and even maven.xml themselves if we will have workflow which might be parametrized. E.g java:compile goal might depend on java:runCodeGenerator goal which by default might be nop. and you will be able to define alias java:runCodeGenerator - > xdoclect:hibernatedoclet. So in the such common cases no scripting will be ever needed. But that's not yet official - that's just one of the possibilties. Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Need to load common goals from sub-projects maven.xml
> -Original Message- > From: Matt Read [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 30, 2004 2:36 PM > To: 'Maven Users List' > Subject: RE: Need to load common goals from sub-projects maven.xml > > > > From: Maczka Michal [mailto:[EMAIL PROTECTED] > > > > > From: Stefanutti, Mario [mailto:[EMAIL PROTECTED] > > > > > > Hi, > > > > > > I looking for a way to set some common goals for each > > sub-project of a > > > multiproject environment. > > > > > Simple soluton: create your own plugin. It is super simple > > (example can be found in Maven Wiki) > > > > Michal > > > > I'm interested in this too. It appears the project's inherit > from the parent > project's maven.xml. Even if one was to write a plugin to > encapsulate common > tasks they would still need to be called in the same way in each > sub-project. I assume inheritance of maven.xml is the > recommended way to do > this? No. Plugins are recommened way of doing this. In Maven 2 inheritence uses the id of the parent project instead of the relative path to parent pom foo bba 1.0 ... Parent pom could be taken from local repository (and hence downloaded there from remote repository) and most likly it might be also provided by reactor when reactor powered build will be used for building both child and parent projects We still haven't decided if maven.xml will be also uploaded/downloaded to/from the repository(ies) but at the moment for sake of simplicity we are rather willing to push all centralized goals to plugins. Plugins can be decalred as any other dependenies in poms and automatically fetched by maven. It means that for common scripts - you will need to create one more project. In reactor powered builds which will be way simpler than thay are now there should be really no differnce as plugin project will be build in the same run of maven and made directly visible to other projets. But this is the future :) [..] Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Need to load common goals from sub-projects maven.xml
> -Original Message- > From: Stefanutti, Mario [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 30, 2004 1:16 PM > To: Maven Users List > Subject: Need to load common goals from sub-projects maven.xml > > > Hi, > > I looking for a way to set some common goals for each sub-project of a > multiproject environment. > Simple soluton: create your own plugin. It is super simple (example can be found in Maven Wiki) Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: RFE for the war plugin
> -Original Message- > From: Brill Pappin [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 29, 2004 10:41 PM > To: Maven Users List > Subject: Re: RFE for the war plugin > > > > Michal Maczka wrote: > > > > Have you tried to do it with the war? Coulpe of times. With different result sas some servlet contanier refused to work with them. > Did you even read that spec? Obviously not. > The classloader loads the jar and the respective versioning > information > not the webapp container that loads the war! Right classes and files in WEB-INF/classes META-INF are not loaded by any classloader. Gradma loads them. > Remember that in this day and age all list mail gets archived so what > you just said above will be preserved forever. > Here is what spec says: "Web containers are recommended to have a mechanism by which web applications can learn what JAR files containing resources and code are available, and for making them available to the application. Containers should provide a convenient procedure for editing and configuring library files or extensions. It is recommended that Application developers provide a META-INF/ MANIFEST.MF entry in the WAR file listing extensions, if any, needed by the WAR. The format of the manifest entry should follow standard JAR manifest format. In expressing dependencies on extensions installed on the web container, the manifest entry should follow the specification for standard extensions defined at http://java.sun.com/j2se/1.3/docs/guide/extensions/versioning.html. Web Containers should be able to recognize declared dependencies expressed in the manifest entry of any of the library JARs under the WEB-INF/lib entry in a WAR. If a web container is not able to satisfy the dependencies declared in this manner, it should reject the application with an informative error message." So realy the spec makes no difference between any of the manifest files which are provided inside wars and clearly defines where they can be placed. But for strange reason it says: "It is recommended that Application developers provide a META-INF/MANIFEST.MF entry in the WAR file listing extensions". Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: RFE for the war plugin
> -Original Message- > From: Brill Pappin [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 29, 2004 2:54 PM > To: Maven Users List > Subject: Re: RFE for the war plugin > > > Where this flack is coming from? > > The reason I specifically want to do it, is so I can use the > manifest to > package extended information about the classes. What's the difference bewtween manifest file kept in META-INF folder of your web application and WEB-INF/your.jar!/META-INF/? > I think I said that though... as for not "convincing", that > assumes that > the way you do things is the right way... I wasn't trying to convince > anyone. > Nope. You asked us to do some work and change war plugin. Before anybody will bother to apply your patch or spend its time trying to implement what you want there are two conditions which must be satisfed: a) there must be an agreement between maintainers of given plugin that this patch is a move into right direction b) somebody must feel that it is important enough to dedicate its time to apply such patch. Most of the plugins are improved thanks to feedback and suggestions of maven users. And we do appreciate suggestions and feedback. But sometimes two users have clashing requirements ( I am myself also a user of war plugin and in some cases for some reasons I really need to have classes in WEB-INF/classes folder). If you are not convincing enough you have 0% of chances that such change which your are asking for will be ever made. > I guess I'm surprised that people don't even want the *ability* to > package as a JAR instead of in the classes dir. Frankly with > my style, > I'd package into a jar instead even if I wasn't interested in the > manifest just to keep things what I would think of as tidy. > so you have been given clean solution how to do that (use one more project for creating your jar and then package it into war) Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: RFE for the war plugin
> -Original Message- > From: Brill Pappin [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 29, 2004 2:38 PM > To: Maven Users List > Subject: Re: RFE for the war plugin > > > Yes, I thought of doing that very thing :) > however I then have problems with Eclipse as it doesn't understand > multi-project builds, and you really want all the parts of an > application in the same place. > > Still doable, but less than optimum. > Can you provide at least one valid reason why would like to do that (put jar file into WEB-INF/lib folder)? All the points you mentioned in you original post are either not very convincing or false (e.g. that size of war thanks to that will be smaller). Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: RE : diff between jar:deploy[-snapshot] and ear:deploy[-snaps hot]
I think Brett started to unify those things and merging deploy and artifact plugins. What he did was looking OK to me. He asked some questions but at that time he got no feedback from me reagrading how it is going to look in m2/wagon I don't think that we are yet ready with those things in m2 (we are constantly progressing in good direction :)) and once we'll have proven solution then we can think how it can be used in case of m1. We are not there yet... Brett: if you still have some questions regarding my code in artifact plugin or how deploy should work in m2/wagon please shoot! Michal > -Original Message- > From: Heritier Arnaud [mailto:[EMAIL PROTECTED] > Sent: Monday, June 21, 2004 5:00 PM > To: Maven Users List > Subject: RE : diff between jar:deploy[-snapshot] and > ear:deploy[-snapshot] > > > Hello Marcin, > > I think that ear, war and newer plugins use the artifact > plugin to deploy. > > You must define properties like it is explained here : > http://maven.apache.org/reference/plugins/artifact/properties.html > > Arnaud > > > > -Message d'origine- > > De : Marcin Maciukiewicz [mailto:[EMAIL PROTECTED] > > Envoyé : lundi 21 juin 2004 16:35 > > À : Maven Users List > > Objet : diff between jar:deploy[-snapshot] and ear:deploy[-snapshot] > > > > > > > > Hello folks. > > v.: 1.0-rc3 > > > > It's about remote repository deployment.According to the: > > http://maven.apache.org/reference/user-guide.html#Behavioural_ > Properties > my $HOME/build.properties provides "maven.username, > maven.remote.group, > maven.repo.central, maven.repo.central.directory" properties. > > They are enough for jar:deploy goal but ear:deploy says that: > "No remote repository was defined." > > I see problems with ear:deploy and ear:deploy-snapshot. > Those goals are implemented differently from jar:deploy's. > Probably they expects different properties to work - sounds > like a bug. I'm not sure. Can anyone explain this? > > Workaround: > Copy-pasted jar:deploy[-snapshot] goals code into ejb plugin > with some > replaces should help. > > -- > Marcin Maciukiewicz > [EMAIL PROTECTED] > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Local & Remote Repositories
> -Original Message- > From: Onno van der Straaten > [mailto:[EMAIL PROTECTED] > Sent: Monday, June 21, 2004 1:41 PM > To: [EMAIL PROTECTED] > Subject: Local & Remote Repositories > > > Group, > This is problably easy but I am new to Maven. > I managed to get my jar into the local repository. Now I am trying to > compile another project that depends on this jar. Maven looks > for the jar in > ibiblio-repository and so the build fails. > How can I make Maven use the jar in the local repository? > Thanks, > Onno Maven won't look for jars in remote repository(ies) if it exists locally (with small exception for SNAPSHOT artifacts). If maven is not finding your jar in your local repo and it is there - it means that you haven't provided the right location of it. So what you have to do is just to declare a correct dependecy on it. Use dependecy tag in you POM with correct groupId, artifactId and version which matches jar's location in your local repository. Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jar help
> -Original Message- > From: Bielby, Randy J [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 15, 2004 3:12 PM > To: Maven Users List > Subject: RE: Jar help > > > Mikal > > Unfortunately, if my project choses to use Maven we will be the only > project doing so here. There are probably 200 other apps in > production > plus 20-30 currently under development. So, I will have to conform to > what the corporate standards are, regardless of my build > tool. That may > mean duplicate maintainence as far as storing jars etc, in a > repository. > > Definitely maven is build tool which is defining its own standards and refusing to work smoothly with the projects which are off those standards. I am sure that most of the companies don't use any standards when if it comes to artifact management systems defining common project layout, standaring build scripts, keeping tracks of project's dependencies, generation of uniformed documentation for projects and so on. I wonder if you can taken radom developer in your comany which has not been working for project "A" and if he will know without looking at any build scripts how he should build jar file of that project or if he will be able to tell you excatly what are the dependecies of this projects and what are the version of those dependecies. And this is just a peek of an iceberg. If your company has such standards then it might be that maven standards are not attractive for you. In any way as far as I know we have no plan to make maven much more flexible and mandate the pratices which we find to be antipatterns. That's our conscious choice. Simply there is a lot of build system with ant and its derivates being currently the most prominent and there is really no need for developing one more similar build system. > Like it of not, this is the reality of large corporate > development where > standards and best practices are sometime mandated based upon a wide > range of criteria. Most of which have nothing to do with the > day to day > work of the developers in the trenches (see Tim Reilly's post) > Agreed :( (but I would rather call it a lack of standards then standards) Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jar help
[...] > >Not really. Maven repository is competly different beast then > >SCM repository > >and provides different features. > > > > Is it? Or is it just a difference of access protocol, http > vs pserver? > Yes, I know that versioning etc is not part of the repo, but > from a very > basic view of a jar containment mechanism, they could be used > interchangably. I'm not that familiar with the plugins, but I would > guess that I could implement a repostory plugin that access a cvs > repository rather than a Maven one. By basically creating a module in > cvs that had contents very similar to a Maven repo, I could in theory > accomplish the same thing. > Yes it is different. First of all binary artifacts are not well handled by SCM repositories and versioning mechanism which is used by SCM is rather useless for them. E.g. you cannot easily check-in an artifacts and require that this is version 1.2.7 of log4j. Also metadata which is needed by maven repositories is different. Say that you have jar file and you want to find matching javadoc artifact or jar with sources (might be useful for debugging) SCM repositories don't provide any facility for that. It is true that you can theoretically use SCM repositories as maven repositories but if you do that you are probably not using a single feature which they provide (maybe with exception for security mechanisms). So from maven point of view there is no difference if artifacts are accessed from local file system or cvs repository (except of course of protocol which is used) > >> If the repo had an interface to CVS it then might become > >> more "sellable" in a corporate environment. That way all > >> components of > >> an application are contained with a single source control > mechanism. > > > >Jars and other generated artifacts are not "sources" and SCM > system are > >really useless for them. > >Are you going to keep javadocs in cvs as well? > > > > No they are not sources, but the ARE components that contribute to the > overall completion of the resulting artifact. There fore > they should be > under some kind of version control mechanism. In Maven case, that > mechanism is the Maven repository. And instead of the version > attributes of a given file being a relationship to the file, > it is part > of the name of the file. From and auditing standpoint, I have to be > able to recreate an EAR from a single repository. Plus I'm > not sure we > would pass an internal audit if some of our distributed binary was not > maintained internally. And then to top it all off, we have an > additional deployment tool (Harvest/AllFusion) for deploying to all > tiers above our development tier. > I am not sure if I understand you. Why would any of your binaries couldn't be maintained internally? Are you aware of the fact that maven works well without the access to ibiblio and only with intranet repositories? And how can you audit your projects if an audit tool cannot dig the information which artifacts were used in your projects? Maven repositories can be also used for deploying artifacts like report results. So you can for example track changes of the projects like test coverage, total number of tests and what ever else you want. I don't really think that those kind of artifacts should be kept in SCM systems. In fact I think that almost never "generated" artifact should be kept in such system. SCM systems are intend for keeping sources. Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jar help
> -Original Message- > From: Bielby, Randy J [mailto:[EMAIL PROTECTED] > Sent: Monday, June 14, 2004 5:17 PM > To: Maven Users List > Subject: RE: Jar help > > > First let me say that I really appreciate the responses I > have recieved > on this issue. They have been very helpful in at least giving me a > start as to how to resolve this challange. I have been on other list > servs of this type where responses are critical, arrogant and > basically > useless. Not the case here... many thanks. > > As far as John's response, I can see the need for this structure and > methodolgy. But I struggle with this for a couple of reasons. > > 1 - My development staff is used to keeping their workspace > in sync with > CVS and doing so thru the WSAD interface (ie Eclipse CVS perspective). > I'm not that concerned with "bloating" out the CVS respository. Those > jars in the WEB-INF/lib typically do not change that often, if ever. > But they are duplicated on other projects, which I have no > control over. > So, if I were to switch to the Maven approach, as right as it might > seem, I would then have to require developers to use two > tools, CVS and > Maven, to keep their workspaces current. I guess you could > argue that I > could eliminate the direct access of CVS and do that via > Maven, but I'm > not sure I want to go that route. I'm in a large IT shop and swimming > upstream like this is not something I enjoy. Due to the internal > corporate economy and corporate politics, our development structure is > very fragmented into smaller development teams all working on the same > code base. The current build mechanism for developers is > WSAD and CVS, > introducing Maven may be more then I want to bite off. And in reality > more then the staff here could handle I'm not saying I don't > agree with > John, as I do. It's just that the reality in large corporate > environments like mine, sometimes do not lend themselves to change. I > am also swimming upstream with standards that are being > mandated outside > of my area that do not fit with a tool like Maven. In fact I'm > struggling to keep Ant and CVS as my build tools. > > 2 - While the idea of the Maven repository is nice, does it > really make > sense in the context of corporate development? It makes much more sense in coorpoarte env. then in case of small open source project as in cooroprate evn, you need much more often to share and distiribute software artifacts in a standard way. >There are > many pieces of > an application that get assembled to create the end result, > the artifact > if you will. By introducing the Maven repo, we have now introduced an > additional repository as input for the build and development > process. I > would rather have a single source for all of the components of my > artifact. In this case CVS. While I think that the repo works very > well for some fo the open source projects etc, I think it > introduces an > additional point of potential inconsitencies, at least in my > environment. Not really. Maven repository is competly different beast then SCM repository and provides different features. > If the repo had an interface to CVS it then might become > more "sellable" in a corporate environment. That way all > components of > an application are contained with a single source control mechanism. Jars and other generated artifacts are not "sources" and SCM system are really useless for them. Are you going to keep javadocs in cvs as well? > And if I could convince others outside of my immidiate team > of the need > for a centralize repository for components/jars, this might be an > interesting endeavor. > > Don't get me wrong, I do agree with most of what Maven is about. I am > just having to pick and choose my battles based upon corporate culture > and desicions that are being made outside of my control. > > I'd be interested in hearing how others are maintaining an updated > workspace for developers while the build process is utilizing Maven. > > Randy Bielby > Don't get me wrong either: With maven we are trying to realize certain philosophy of build system. We are not looking for very flexible build system which is able to build any java project with radom structure like ant does. If somebody does not share our vision he might happier with other build system. Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: XML entities and forward compatibility
> -Original Message- > From: Jörg Schaible [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 09, 2004 10:03 AM > To: Maven Users List > Subject: RE: XML entities and forward compatibility > > > Maczka Michal wrote on Wednesday, June 09, 2004 9:33 AM: > > Because > > > > a) How would you deploy POMs which contains external XML > > entities to say ibiblio? The same problems - diffused files - > > may affect continuous integration tools - more files more > > problems to deal with > > > This is not a problem of the entities!!! I already stated > that some time ago. Look at M1 multiprojects. The deployed > pom's of their subprojects are useless also! If you would > extract the resolved POM from memory and deploy that ... you > would solve the real problem. I am not sure if I know what you mean but in m2 parent POM will be referenced differently (not by the way of giving path to it) and reactor will be built-in into core. Also raw model is well separated from inherited and interpolated values. > > > b) XML representation of POM is not the only available and I > > hope we will be using mini databases for keeping them > >as this will enable faster processing. XML entities hve > > really no meaning for databases and they are not so friendly > >for futute tools like visual POM editor. > > > And how would you deploy a POM contained in a DB? Same as (a) > yeap. > c) (most important) They won't be needed > > > That's my use case for M2. Currently with M1 I have several > Multiproject that have a dependency on each other. With > company wide entity definitions I manage even inter-project > dependencies and their versions. This means there is e.g. > only one xstream version that is used company wide, although > a multiproject may overwrite this version-entity for its > subprojects. This ensures largely, that all unit tests for > all subprojects in all multiprojects that have to work > together use (normally) the same versions and I will not be > bitten by incompatible versions in the dependencies running > my app in the test (or live) env although all unit test were > originally working (but only with their project's specific > version). SUch a mechanism I would like to achive also with M2. > There are few things which will be vanished by transitive dependencies: Now all project which were using xstream or whcih were using libraries which we using xstream have to declare a dependency on xstream. With transitive dependencies in place the number of POMs which have to do this will be greatly limited. This will already make maintenance a lot easier. Secondly we hope to have some tools which will help you manage your POMs. Say you will be able to group projects and with GUI tool update the version of the given dependency in all those projects. Or imagine ci system doing that for you when new, fully backward compatible version of xstream is released. And there are some other cool things coming E.g. you will be able to use your own types of dependencies and artifact handlers for creating artifacts from them. If someone will wish he might be even able to write artifact handler which will read other POMs or even use web services. I doubt if such complex things will be ever needed but that is something which will possible. Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: XML entities and forward compatibility
> -Original Message- > From: Dion Gillard [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 09, 2004 3:24 AM > To: Maven Users List > Subject: Re: XML entities and forward compatibility > > > Given that they're a standard part of XML, and that the m2 project > descriptor in one form will be an XML document, why would they not be > available? > Because a) How would you deploy POMs which contains external XML entities to say ibiblio? The same problems - diffused files - may affect continuous integration tools - more files more problems to deal with b) XML representation of POM is not the only available and I hope we will be using mini databases for keeping them as this will enable faster processing. XML entities hve really no meaning for databases and they are not so friendly for futute tools like visual POM editor. d) imo ideally round trip XML -> Bean Model --> XML or XML --> DB --> XML should leave POM untouched. And it will be hard to do this with external entities c) (most important) They won't be needed michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: failover for maven repository?
you can use: maven.repo.remote=http://repo1,http://repo2,file://repo3,http://www.ibiblio. org/maven and so on Michal > -Original Message- > From: Julian C. Dunn [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 08, 2004 3:51 PM > To: Maven Users List > Subject: failover for maven repository? > > > Hello, > > I'm wondering if there is any way to get Maven to fail over to one or > more repositories when ibiblio.org is unavailable, or does not contain > the JARs that I'm looking for. > > It seems like the "maven.repo.remote" knob is an > all-or-nothing deal; if > I want to pull certain JARs from my local repository, I have to mirror > *all* of the ibiblio JARs I want. > > Similarly, if I don't set "maven.repo.remote" to anything, I can't > override one particular JAR by pointing it to a local > repository; i.e. a > maven.jar.foo property can only refer to a local filesystem > path, not an > internal repository URL. > > Is this a limitation of Maven, or of my understanding of how to > configure it? > > - Julian > > P.S. Anyone know why xalan 2.6.0 is missing from ibiblio? > > -- > Julian C. Dunn, B.A.Sc. <[EMAIL PROTECTED]> > Software Developer, CBC New Media Operations > Office: 2C310-I * Tel.: (416) 205-3311 x5592 > > - > 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: Dependency Inheritance
I guess that you are mixing two terms: project inheritence (dependencies are already inherited and you can use this feature) and transitive dependecies. Support for transitive dependencies is planned since a long time and already exists in m2. Michal > -Original Message- > From: Michael Mattox [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 08, 2004 10:46 AM > To: Maven-users > Subject: Dependency Inheritance > > > I have a project A that depends on project B. Project B has 10 JAR > dependencies. I've found that I must list the 10 JAR dependencies in > Project A's project.xml file. Is there a way to inherit > dependencies? I > understand there is a potential problem with version > conflicts (project A > wants to use a newer version of commons logging than project > B) but at the > same time I think having to duplicate these JARs in every > project.xml is > troubling. In my case project A is called "common" and is > used by 15 other > projects. Any ideas? > > Regards, > Michael Mattox > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Setting path for tests
This should work: String basedir = System.getProperty( "basedir" ); File dll = new File( basedir, "/realtivePath/toYourDll" ); Michal > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 03, 2004 4:16 PM > To: [EMAIL PROTECTED] > Subject: Setting path for tests > > > Is there any way to set the (Windows) path to be used when > running the Junit > tests through Maven? > > There's a JNI dll I need to pick up, but I want to refer to > it relative to > the project I'm building (i.e. setting the machine wide path > isn't an ideal > solution) > > thanks > > James > > > -- > -- > For more information about Barclays Capital, please > visit our web site at http://www.barcap.com. > > > Internet communications are not secure and therefore the Barclays > Group does not accept legal responsibility for the contents of this > message. Although the Barclays Group operates anti-virus programmes, > it does not accept responsibility for any damage whatsoever that is > caused by viruses being passed. Any views or opinions presented are > solely those of the author and do not necessarily represent > those of the > Barclays Group. Replies to this email may be monitored by > the Barclays > Group for operational or business reasons. > > -- > -- > > > - > 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: why jar:deploy uses diffrent deploy plugin
Becouse artifact plugin is not yet able to handle deployments of maven artifacts (jars) to ibiblio in the way which ia as secure as the way in which deploy plugins does it. New code which will unify those plugins and do much more is mostly ready and will be mostly likely merged with maven after 1.0 release as the changes are quite substantial. Michal > -Original Message- > From: Marcin Gurbisz [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 03, 2004 9:08 AM > To: Maven Users List > Subject: why jar:deploy uses diffrent deploy plugin > > > Why jar:deploy uses different plugin to deploy aritfact then > for example > ejb plugin? > It interfere me with consistent project artifact deploying. > > Thanks, > Marcin > > - > 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: [ANN] Mevenide releases
> -Original Message- > From: Arto Pastinen [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 02, 2004 12:30 PM > To: Maven Users List > Subject: Re: [ANN] Mevenide releases > > > No. There really is RC1. Build at Sat, 29 May 2004 -- 01:05 (-0400). > See: http://www.eclipse.org/downloads/index.php > Yeap! You right. I am almost sure that I read somewhere taht m9 = rc1. Sorry for confusion michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Dependancies without repositories. Was: Re: Dependencies
> -Original Message- > From: Brill Pappin [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 01, 2004 9:04 PM > To: Maven Users List > Subject: Re: Dependa [...] > > You mean the situation when devloper is not able to connect to your > > servers from home? > > How can he/she use things like CVS then? And then how > sources of the > > project will appear on his disk? > > You can use the same channel for transfering required > artifacts into > > your local repository. > > > > Yes, that is a good example, and we have more levels of security here > than simply ssh, including rotating tokens which Maven > *can't* know about. > Also "automatic" is a dirty word around here and no "automatic" cvs > access is permitted in any build or deployment script. > I didn't mean that you should use any script. I meant that person who works "outside" __at least-__ in the worst case can come into possesion of required artifacts in the same exact way as it takes places with project's sources. if this is cvs + ssh he should be also able to checkout jars from cvs if this is an email he can recieve a zip bundle containg sources and required jars and so on [...] Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [ANN] Mevenide releases
> -Original Message- > From: Peter Bright [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 02, 2004 11:35 AM > To: 'Maven Users List' > Subject: RE: [ANN] Mevenide releases > > > I presume him to mean "use Eclipse 3.0 M9 or 3.0 RC1". RC1 > is available, > but it doesn't seem to be mentioned on eclipse.org (at least, > not that I can > see). I guess that Eclipse RC1 = M9 michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Adding artifacts to local repository - how?
> -Original Message-
> From: Antonio Bemfica [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, June 01, 2004 4:43 PM
> To: Maven Users List
> Subject: Re: Adding artifacts to local repository - how?
>
>
> I do not have the source to create the jars. These are 3rd party
> libraries. From the docs on the plugin it appears that the jar:install
> goal would trigger the jar:jar goal to create the jar from
> source (which
> I don't have...).
>
Why cannot you do this manually?
You just create a folder
${repo.local}/${your_group_id}/jars
and put all your jars there
Michal
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: deploy:artifact confusion
> Is there a workaround for this? Use zip >I'm not sure I follow the > reasoning for > why you'd need to change the extension when deploying? isn't > that left > to the plugin that created the artifact? war, ejb, jar, ear etc? I > guess it's not a problem to have zip files with a .example > extension as > long as they're to be accessed programatically, but I was thinking of > having links to my 'example' artifacts so they could be downloaded. > Probably it was a mistake from my side but I wanted to have a guard which stops you from deploying/installing to maven repositories artifacts which cannot be downloaded by maven. The implementation is mostly symmetrical with artifact downloading routines in maven core When you have artifact of type "example" ( example ) it has to have extension .example and reside in the folder "examples". Only maven plugins and ejb jars are handled in a special way. This is something we want to change in close future and make it to certain degree customisable. Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: deploy:artifact confusion
> -Original Message-
> From: Nathan Coast [mailto:[EMAIL PROTECTED]
> Sent: Friday, May 28, 2004 3:05 PM
> To: Maven Users
> Subject: deploy:artifact confusion
>
>
> Hi,
>
> I have some code in a plugin:
>
There are two plugins artifact plugin an ddeploy plugin which are mostly
overlapping.
This is using deploy plugin:
> artifact="${maven.build.dir}/${maven.final.name}-example.zip"
> type="example"
> assureDirectoryCommand="mkdir -p"
> siteCommand="cd @deployDirectory@;chmod -R g+u *;"
> />
>
> I placed the following in build.properties
>
Those are settings for artifact plugin
> maven.repo.list=R1
>
> #settings for repository 'R1'
> maven.repo.R1=ftp://ftp.codeczar.com
> maven.repo.R1.username=*
> maven.repo.R1.password=*
> maven.repo.R1.directory=/usr/ngasi/contexts/codeczar/codeczar/maven
>
>
[...]
I know this is very confusing - but soon it will be unified (after 1.0
release)
Michal
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: About Dependencies
> -Original Message- > From: Amato Massimiliano (TLAB) > [mailto:[EMAIL PROTECTED] > Sent: Friday, May 28, 2004 1:35 PM > To: Maven Users List > Subject: RE: About Dependencies > > > Hello > > I just didn't know it was possible, are you sure this is > supported since i didn't find it anywhere > Yes I am sure. http://maven.apache.org/reference/user-guide.html#Behavioural_Properties -> see maven.repo.remote I am using something like: maven.repo.remote=http://our_intranet_repo/,http://www.ibiblio.org/maven SO maven first looks for artifact which exits in "closer" repository which makes downloads way faster. you can even do maven.repo.remote=file://xxx/,http://ww.ibiblio.org/maven With file protocol and network drive mapping facility you can even access remote repositories (afaik some OS let you even map FTP, WebDav repositories) Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: About Dependencies
> -Original Message-
> From: Amato Massimiliano (TLAB)
> [mailto:[EMAIL PROTECTED]
> Sent: Friday, May 28, 2004 9:45 AM
> To: Maven Users List
> Subject: RE: About Dependencies
>
>
> Hi Yagmur,
>
> We have the same problem as you since we have a centralized
> Maven configuration and we are behind a firewall and the
> password is forced to be changed every 15 days so we didn't
> want to give Maven internet access from the workstation.
>
> Our solution was to update the maven.jar, we replaced the
> remote repo from ibiblio to a local disk, and then I do the
> upload from the net to the central repo.
>
> This way you'll have to download the needed lib to the
> computer with internet access and the computer with maven
> will download them directly from it
>
> Max
Amato:
Why did you have to "update" maven.jar?
Isn't it just sufficient to edit your ${user.home}/build.properties file
and put there the url of your remote repo? You can even access remote repo
using file protocol is you want.
Yagmur:
> I wonder if there is some way to say maven that it should not download the
dependencies, since i will do the downloads manually.
Maven will download dependencies only if they are not existing in your local
repository.
Once you have you local repository populated and all required jars are in it
everything should work fine and no remote repository is needed.
Population of local repository by the way of fetching artifacts from remote
repository(ies) is the simplest way of doing that.
But you can populate it manually or even check it out from CVS.
Even if you are behind the firewall and you have no internet access you can
often still use intranet repository which can be shared by many users.
Michal
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Inherited properties (RC3)
> -Original Message-
> From: Kevin Pearcey [mailto:[EMAIL PROTECTED]
> Sent: Friday, May 21, 2004 11:36 AM
> To: 'Maven Users List'
> Subject: RE: Inherited properties (RC3)
>
>
> > > I'm having a problem with my subprojects in maven.
> > >
> > > Top level multiproject has the following in maven.properties
> > >
> > > maven.repo.local=../maven-rep
> > >
> > > This value gets inherited by the sub projects, but comes
> > > through with the
> > > same value rather than the desired ../../maven-rep.
> > >
> > > Is there a better way to specify this or the pom inheritance
> > > so that the
> > > file paths get modified as multiproject does down the
> > subproject tree?
> > >
> > >
> >
> > In this particular case there should be only one maven local
> > repo so you should define its location in
> > ${user.home}/build.properties
> >
> > Michal
>
> No, I need multiple local repos so that I can have more than
> one build using
> SNAPSHOTs. Each project gets built with its own local repo so
> that we can
> have different branches, as I understand it there is no way
> to associate
> SNAPSHOT with a version, so our only choice to get multiple
> SNAPSHOTS during
> development is for each branch to uses its own local rep.
>
There is a way. You can use (for both projects and dependecies)
1.0-SNAPSHOT and 2.0-SNAPSHOT
then you should be using only install goals (like jar:install, war:install)
not install-snapshot goals.
Michal
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Inherited properties (RC3)
> -Original Message-
> From: Kevin Pearcey [mailto:[EMAIL PROTECTED]
> Sent: Friday, May 21, 2004 11:05 AM
> To: 'Maven Users List'
> Subject: Inherited properties (RC3)
>
>
> I'm having a problem with my subprojects in maven.
>
> Top level multiproject has the following in maven.properties
>
> maven.repo.local=../maven-rep
>
> This value gets inherited by the sub projects, but comes
> through with the
> same value rather than the desired ../../maven-rep.
>
> Is there a better way to specify this or the pom inheritance
> so that the
> file paths get modified as multiproject does down the subproject tree?
>
>
In this particular case there should be only one maven local repo so you
should define its location in
${user.home}/build.properties
Michal
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: 1 Project, Multiple Atrifacts
> -Original Message- > From: ECCLES, Stuart [mailto:[EMAIL PROTECTED] > Sent: Thursday, May 20, 2004 1:11 PM > To: 'Maven Users List'; [EMAIL PROTECTED] > Subject: RE: 1 Project, Multiple Atrifacts > > > The one project-one artifact pardigm really restricts maven. > > For example my most common production of multiple artifact is > a project > producing both an ejb jar and a Jboss wsr. This can only be > done in one > project because the wsr config and ejb is produced by Xdoclet > from the same > source files. > It is not true that it can be done only in one project. Simply two projects can share the same sources. Project in maven world is not something very heavy it's just a directory with xml file and probably properties files. A B project.xml ( ../A/src/main/java) This works fine at the moment but such pattern might be in future a problem for ci systems (no direct dependecy on A is declared, the path is hardcoded). This is probably something we must think of in m2 and add it to list of use cases which we are considering. Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven and Integration Test
> -Original Message- > From: Ryan Sonnek [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 19, 2004 4:46 PM > To: Maven Users List > Subject: RE: Maven and Integration Test > > > I was REALLY hoping to hear another solution to this problem. > I'm running into the same thing, and would like to contain > my project code (tests and all). I remember the cactus > plugin introducing the concept of src/test-cactus for it's > integration test code. > > Two options would be to reuse the current test plugin and > change the source directory dynamically, or create another > "test" plugin for integration tests that looks to something > like src/test-integration. I think that creating a new test > plugin might make the most sence in order to plug easier into > project reports. How plausible is this? > I think it's the bad idea. You can have quite a few types of integration tests. /src/test /test-cactus /test-stresstests /test-db and so on. It makes it difficult to maintain, difficult to select which type of tests you want to execute and difficult to integrate with plugins like idea, eclipse and so on. the layout: mainproject /src /test java (unit tests) mainproject-iu-catus /src /test java mainproject-iu-stresstests mainproject-iu-test-db is scalable and it will work out of the box with existing test plugin and is supported by idea/eclipse plugins. Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven and Integration Test
> -Original Message- > From: Amato Massimiliano (TLAB) > [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 19, 2004 4:17 PM > To: Maven Users List > Subject: Maven and Integration Test > > > Hello, > > I've a problem with my integration tests. > > In my system we have both unit and integration test, the > first type is perfectly handled by maven that execute them, > and generates a report and a clover coverage too. > > Now I also have integration that are test to cover not the > single class but a package and functional tests that must be > run on the deployed system that are junit tests aswell. > > All that comes to my mind is to write and additional goal > that must override the test source directory that must be > lauched when functional tests wants to be executed, while for > integration i think using them as unit test is the best > approach even if they are not accounted in the clover report > > Anyone else ever had a problem like that? What's the solution > you implemented? > Just put them to another project. Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: 1 Project, Multiple Atrifacts
Everything what can be done with ant can be done with maven. In this case you have to by pass the maven plugin which generates jar and write your own script in maven.xml file. But this is something we discourage. "Subprojects" option is much simpler and cleaner and recommended. > -Original Message- > From: David R Robison [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 19, 2004 1:42 PM > To: Maven Users List; [EMAIL PROTECTED] > Subject: 1 Project, Multiple Atrifacts > > > Is there a way to set up a project that produces 2 jars > without having to setup > sub projects? > > Thanks, > David Robison > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: dependencies
I am not sure if I understad you you will have (for version 1.0) ABC ABC 1.0 XXX XXX 1.0 and (for version 2.0) ABC ABC 2.0 XXX XXX 1.5 YYY YYY 2.0 Michal > -Original Message- > From: Manuel Darveau [mailto:[EMAIL PROTECTED] > Sent: Tuesday, May 18, 2004 10:07 PM > To: [EMAIL PROTECTED] > Subject: dependencies > > > Hi! > > I probably have missed something somewhere but dont > dependencies should be by project-version instead of > only by project? > > I mean, is the project ABC-1.0 could have a dependency > on XXX-1.0 and ABC-2.0 a dependency on XXX-1.5 and > YYY-2.0. > > How does the build system handle this? > > Suppose that I tag my version on CVS with VERSION_M_m. > I can have an old version tagged VERSION_1_0 and newer > one tagged VERSION_2_0. > If I ask to build a project with the CVS tag > VERSION_1_0, does maven checkout the project.xml > tagged as VERSION_1_0 and resolve dependencies with > that version (1.0) of the project.xml? > > Since version 1.0 and 2.0 does not have the same > depdendencies, it make a big difference on the build. > > I may be completely off the track (I am reading maven > doc for 2 days) but please bring me back in the good > direction ;-) > > Thank you > > Manuel Darveau > > > > > __ > Do you Yahoo!? > SBC Yahoo! - Internet access at a great low price. > http://promo.yahoo.com/sbc/ > > - > 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: Xdoclet & Eclipse
> -Original Message- > From: Peter Bright [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 19, 2004 12:14 PM > To: 'Maven Users List' > Subject: RE: Xdoclet & Eclipse > > > Without some kind of defined (and widely used!) mechanism for > source-modifying plugins to do their thing, it's not clear > how they have any > real choice in the matter. Does there exist a better way > that works right > now? I agree with Vicent that pre/post Goals should be not used by plugins. At the moment common pratice is to have a maven.xml file with something like: in it and unfortunatly plugins like eclipse, javadocs etc. are not seeing yet that there are seeing that some java sources were generated We have dissussed this issue sometime ago and if I remember we were close to agreeing that we should add to POM a tag which can be used by all plugins. Later on we can even think about adding other tags like or (e.g javacc or xdoclet) etc once we will be able disovered some common patters and generalize them. In an case no change in POM structure is planned for 1.0 release. Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Again POM Parser in Maven 1
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Tuesday, May 18, 2004 1:41 PM > To: Maven Users List > Subject: RE: Again POM Parser in Maven 1 > > > Hello Michal, > > Entity is an XML feature and the SAX Parser you are using to > do the job > works fine with entities. I debugged remotely the process > generated by > maven.bat and it seems to works fine with the same POM. I am not sure if will support external XML entities in future version of maven as most likly we will have solution which will eliminate the need of having them. I am not sure if it is so obvious what betwixt/digister/sax parser are doing with external entities specially inside unit tests. Can you re-post your POM? It seems that atachments are not allowed in posts to this list. Have you tried to run your tests against any POM which is not using entities? Did they work? > Sorry to bother you but I found that behaviour quite "komisch". That's life :) It's good to have some "fun" but it's better to have a REAL FUN :) Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Again POM Parser in Maven 1
Michele have to tried if it works without external entities? This is not something which is recommended and it was never tested. Michal > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Tuesday, May 18, 2004 9:40 AM > To: [EMAIL PROTECTED] > Cc: Maven Users List > Subject: Again POM Parser in Maven 1 > > > Hello dIon, > > here is the POMs I am using : > > (See attached file: s13.ent)the entity is used among > different category of > projects > > (See attached file: project.xml)the initial POM is relative > to a particular > module > > (See attached file: project.xml)the father is used to group together > property of a single project > > I then use that POM to generate an ear but this part is not > imporatant at > the moment I want to find a way using the API how to parse > the POM and > create a Project rappresentation in memory. > > Best Regards and thanks for your time and above all for the > great job you > all did. > > Michele > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Again about the POM Parser in Maven 1
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Monday, May 17, 2004 2:50 PM > To: Maven Users List > Cc: 'Maven Users List' > Subject: RE: Again about the POM Parser in Maven 1 > > > Probably I have misunderstand you sorry for wasting in > case your time. No problem. Probably you did misuderstand me. I asked you to look at like 106 of this class http://maven.apache.org/reference/plugins/xdoc/xref/org/apache/maven/Depende ncyDescriberBean.html#106 This methods takes dependecy as parameter, constructs the path to corespoding POM, parses that POM and returns it. Either I am missing something but this is more or less what you want to do. The first half of this method contains the code which generates the path which leads to POM, second half shows how to use it when you want to get (parsed) POM. There is no requiremnt that some POM should exists before. So it is not very different from your code and I don't know why your version is not working. Which version of maven are you using? tag was indeed required at some moment in time but that was ages ago... Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Again about the POM Parser in Maven 1
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Monday, May 17, 2004 1:32 PM > To: Maven Users List > Cc: Maven Users List > Subject: RE: Again about the POM Parser in Maven 1 > > > Hello Michal, > > Probably I was not precise enough. My initial aim is to be > able to parse > using the API an already working project.xml. Using the > maven.bat I can > normally work with it. I made before using it in this test also a > verification using the POM plugin. > > No you were precise enough... :) Have you looked at this example which to which I have pointed you. It really does the same things which you want to do ... but it works :) Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Again about the POM Parser in Maven 1
It seems to me that really something is not OK with your POM Maybe this example will be helpful? : http://maven.apache.org/reference/plugins/xdoc/xref/org/apache/maven/Depende ncyDescriberBean.html (you can look at the method private Project resolveProject(Dependency dependency) ) Michal > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Monday, May 17, 2004 11:25 AM > To: Maven Users List > Cc: Maven Users List > Subject: Again about the POM Parser in Maven 1 > > > > Thanks for the hint to point to MavenUtils, I played around a > bit with that > class, using a know working project.xml. I wrote a small test > [...] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: POM Parser
The code you are refering to is a part of maven2 code base. It hasn't yet even reached alpha stage and it is not ready for public consumption (everyday there are some changes in the api). What you are trying to do (perstist POMs in the database) is also in our plans. So we cannot offer any direct help at the moment... regrads Michal > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Friday, May 14, 2004 1:15 PM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: POM Parser > > > For my project in order to make it persistent the information > gathered by > the POM of an application we want to store that in a > database. Being the > POM Parser a fundamental part of that concept, instead of > writing my own > one, I noticed that there is already a POM parser and the > corresponding > Model to populate in maven-components and in particular in the > > maven-project module. > > I noticed that those classes are not distributed with the > maven.jar that > normally comes with the public distribution. > > In the maven repository at ibiblio I could only find > maven-model-2.0-ARTIFACT.jar > > Is there anyone who could shed some light on that arguments > and in case > point me to a location where I could get the > maven-project-version.jar ? > > Any help is welcome > > > Michele > > > This e-mail, including attachments, is intended for the person(s) or > company named and may contain confidential and/or legally privileged > information. Unauthorized disclosure, copying or use of this > information > may be unlawful and is prohibited. If you are not the > intended recipient, > please delete this message and notify the sender > > > > > - > 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: Suggested Eclipse Plugin Extension
> -Original Message- > From: M.-Leander Reimer [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 12, 2004 4:59 PM > To: Maven Users List > Subject: Suggested Eclipse Plugin Extension > > > Hi there, > > I just got the source for the Eclipse plugin from CVS and discovered > that I can already define additional "natures", which I really need. > There is another possible extension I would find useful. > > Problem: I am using the Together UML eclipse plugin, which requires > additional settings in the .project file, e.g. a directory where it > stores its model files, like > > > > > Solution: Would it be possible to include a custom merge file > that could > hold such information at the end of the project.jelly file > (just before > the closing ), like > > > > Well it works for me :-) , so the question is, would it be > possible to > include this permanently into the Maven eclipse plugins source?? > Isn't it just much simpler to keep .project .classpath files in the CVS. .project file is even not changing that often (to my knowlegde almost never). I don't think that polution of maven's project.properties files with dozen of configuration settings for generating eclipse project descrptors makes much sense. You are in addition proposing even custom project.jelly file which in fact makes it even more complicated to maintain. Why would you prefer to keep in cvs project.jelly and not directly .project file? Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: sftp deploying artifacts problem
I have no clue why files are not "there"... Have you tried with scp://? Are you sure that you have access right to this direcory? Have you tried if you can use sftp with tools like "SSH Secure Shell for Workstations"? Michal > -Original Message- > From: Marcin Gurbisz [mailto:[EMAIL PROTECTED] > Sent: Tuesday, May 11, 2004 4:12 PM > To: Maven Users List > Subject: sftp deploying artifacts problem > > > Hi, > > I've got a problem with deploy goal. I use following settings in > properties.xml: > maven.repo.remote=http://www.ibiblio.org/maven,http://www.pent > acomp.pl/maven > maven.repo.list=pentarepo > maven.repo.pentarepo=sftp://192.168.3.6 > maven.repo.pentarepo.username=mgu > maven.repo.pentarepo.password=xxx > maven.repo.pentarepo.directory=/opt/maven > maven.repo.pentarepo.port=22 > > Everythink seems to be OK, but there are no files on the server after > all. Do you have any idea?. > Maven logs: > > Will deploy to 1 repository(ies): pentarepo > Deploying to repository: pentarepo > host: '192.168.3.6' > Deploying: > D:\pentacomp\maven\sandbox\ejb-nazwa\project.xml-->maven-examp > le/poms/nazwa-ejb-1.0-SNAPSHOT.pom > ## > Deploying: > D:\pentacomp\maven\sandbox\ejb-nazwa\project.xml.md5-->maven-e > xample/poms/nazwa-ejb-1.0-SNAPSHOT.pom.md5 > # > Will deploy to 1 repository(ies): pentarepo > Deploying to repository: pentarepo > host: '192.168.3.6' > Deploying: > D:\pentacomp\maven\sandbox\ejb-nazwa\target\nazwa-ejb-1.0-SNAP > SHOT.jar-->maven-example/ejbs/nazwa-ejb-1.0-SNAPSHOT.jar > # > Deploying: > D:\pentacomp\maven\sandbox\ejb-nazwa\target\nazwa-ejb-1.0-SNAP > SHOT.jar.md5-->maven-example/ejbs/nazwa-ejb-1.0-SNAPSHOT.jar.md5 > # > BUILD SUCCESSFUL > Total time: 14 seconds > Finished at: Tue May 11 15:56:37 CEST 2004 > > Marcin > > - > 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: compatible jars
One more time: - use POM to documenting dependencies of your version of
struts (put it ${repo}/struts/poms/struts-1.1.pom).
Once we will have a version of maven which supports transitive dependencies
(we should have it soon) you won't be even required to declare indirect
dependencies in your projects POM.
You will have to only declare dependency on given version of struts. Struts
own dependencies will be resolved by Maven.
Michal
> -Original Message-
> From: James Hughes [mailto:[EMAIL PROTECTED]
> Sent: Monday, May 10, 2004 10:00 AM
> To: Maven Users List
> Subject: Re: compatible jars
>
>
> That's what I have ended up doing. Some projects don't need
> struts and do
> use commons-, so I've ended up with duplicates where a
> jar may be in
> the 'struts' group as well as in it's own group. I still
> wonder how other
> people do it considering that the ibiblio repository is not
> strutured like
> that.
>
>
>
>
>
> [EMAIL PROTECTED]
> 08/05/2004 08:40
> Please respond to "Maven Users List"
>
>
> To: "Maven Users List" <[EMAIL PROTECTED]>
> cc:
> Subject:Re: compatible jars
>
>
> Why not just use a groupId of struts for the commons jars?
> --
> dIon Gillard, Multitask Consulting
>
>
>
> "James Hughes" <[EMAIL PROTECTED]> wrote on 07/05/2004 11:43:39 PM:
>
> > Does Maven provide a mechanism for documenting/specifying
> compatible
> > artifacts across groups in a repository?
> >
> > For example, the struts distribution bundles a number of jars from
> jakarta
> > commons. This implies that the struts jar/runtime depends
> on particular
>
>
> > versions of the commons jars, but if I am putting struts
> into my local
> > repository for the first time I have to split up this
> grouping into it's
>
>
> > constituents, thus losing the implicit documentation of strut's
> > dependencies. Now when I come back in a year's time to
> create a new
> > project which uses struts, I have to figure out the
> compatible jars from
>
>
> > scratch. Is there anything in Maven to help me with this problem?
> >
> > Thanks,
> > James.
> >
> >
> -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Dependency management
> -Original Message- > From: Dominik Dahlem [mailto:[EMAIL PROTECTED] > Sent: Monday, May 10, 2004 12:20 PM > To: [EMAIL PROTECTED] > Subject: Dependency management > > > Hi, > > I'm wondering which way maven is going in terms of dependency > management. In my scenario and most I'm aware of, I'd like to > distinguish between different types of dependencies to support e.g. a > clever distribution of the application. > I'm thinking of three types: compile time, runtime, and test > dependencies. The distinction of those would help me in my > scenarios to > create a binary distribution including only the dependencies I need to > run the application. Another distribution might be targeted to > developers who need the sources as well as the compile-time and test > dependencies. > > What do you think? Is that already doable with the latest > maven? If not, > is it an interesting feature for future maven releases? > This is a thing which is planned since a long time and has been dissussed many time at our mailing lists and we have it in our schedule... Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: protecting remote repositories
> -Original Message- > From: Dominik Dahlem [mailto:[EMAIL PROTECTED] > Sent: Monday, May 10, 2004 12:33 PM > To: [EMAIL PROTECTED] > Subject: protecting remote repositories > > > Hi, > > in an earlier post Guillaume Lasnier was interested in > protecting remote > repositories. At [1] there is a short introduction into using wagon as > the general artifact handling library in maven. I'm curious about the > status of the work in embedding wagon into maven. Is it already usable > in the latest CVS maven? Where can I find more information about it? > This is still the work in progress (I am actively working on it now). We are at alpha stage at the moment and api is still unstable (code itself is quite stable). I think we should be ready some thing usable solution in few weeks rather then in months but we have no plan to use Wagon or anything revolutionary for 1.0 release. Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [maven2] Anything Groovy in Maven2?
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Sent: Monday, May 03, 2004 1:36 PM > To: Maven Users List > Subject: Re: [maven2] Anything Groovy in Maven2? > > > Trygve Laugstøl <[EMAIL PROTECTED]> wrote on 03/05/2004 > 08:43:15 PM: > [snip] > > > I relly don't thinkt this is so bad. Most of the plugins > are much more > than > > one liners and as you can see the overhead for each file here is 4 > lines. > > 4 lines, and it's not as functional. The Maven2 clean plugin > is over 100 > lines of java. The jelly version is just over 10. We're > talking orders of > magnitude more code, and the Ant codebase is well tested, as > evidenced by > the copying of bizarre code from it into Maven2. I don't think it will be that bad. Now clean, jar, compile plugin and it's goal can be easly reused in other plugins (e.g you don't have to write the same code for test plugin). My main problem with jelly/current design is that it disallows to reuse the code easly. See how test plugin is similar to java plugin. Duplicated code = no consitency = bad design. More over nobody else was ever reusing our long jelly scripts. With simple Pojo stratgey we might even serve as source of ant tasks! Once we will cover basic functionality (it's not that far from now) we will have our own building blocks which will enable fast development. I believe actually that we will be much faster after passing some point then we are now. > > > On the upside the plugins will be much easier to test and > will run fast > as > > hell. > > Definitely, but this doesn't help people write them first time. > Sure. But I don't know a single person which tried to implement something with jelly which was really productive. I dare to say that it will be much faster to write plugins in Java then in jelly. I spent myself hours doing something horribly basic in jelly. And note that number of users of plugins in not comparable with the number of plugin devlopers. Most people just use the plugins and the way it is implemented is not importand for them regards Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Mysterious "no goal" [xdoc]
Have you tried to clean your plugin cache? Michal > -Original Message- > From: Christian Nill [mailto:[EMAIL PROTECTED] > Sent: Monday, May 03, 2004 12:32 PM > To: Maven Users List > Subject: Mysterious "no goal" [xdoc] > > > Hello, > > I have a mysterious problem where maven doesn't "want" to use > its xdoc-Plugin (v 1.6 on > rc2). On one day invoking the site:deploy goal caused no > problems while on the other day > the build fails like this: > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: snapshot dependencies
> -Original Message- > From: Flesner, Dan [mailto:[EMAIL PROTECTED] > Sent: Tuesday, April 27, 2004 9:21 PM > To: Maven Users List > Subject: snapshot dependencies > > > i'm confused by snapshot dependencies. when i do an > install-snapshot to > build the local dependencies i get the following in my local > repository: > > -rw-r--r-- 1 dflesner dev12728 Apr 27 12:03 > smc-impl-20040427.190310.jar > -rw-r--r-- 1 dflesner dev12728 Apr 27 12:16 > smc-impl-20040427.191611.jar > -rw-r--r-- 1 dflesner dev12728 Apr 27 12:16 > smc-impl-SNAPSHOT.jar > > it appears that the -SNAPSHOT came from the remote repository and the > -2004XXX came from the local install-snapshot. which jar is > used locally > to compile with by other dependencies? why not just update the local > -SNAPSHOT and not the -2004XXX files? are the -2004XX files ever used > anywhere? now i have to periodically clean out my local repository of > all the -2004XXX versions when i run out of disk space. > > what is the best practices for using install/deploy snapshot, am i > missing something here? > Yes you are :) http://maven.apache.org/reference/user-guide.html#Resolving_SNAPSHOT_Depende ncies In short: when you make a release of your project you should (at least it is highly recommended) replace snapshot dependencies with timestamped ones. This is simply because SNAPSHOT artifact can evolve after your release and you want to preserve the possibility of reproducing the release and (this is even more important) have well defined list of dependencies with which given version of your project is known to work with. Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: multiproject:site - POM outside main dir tree isn't included
> -Original Message- > From: Fabio Uechi [mailto:[EMAIL PROTECTED] > Sent: Tuesday, April 27, 2004 1:39 PM > To: Maven Users List > Subject: Re: multiproject:site - POM outside main dir tree isn't > included > > > > Hi Michal, > > The workaround you told me worked! > Only one correction: > > I had to set the property "basedir" and not "includes": > > maven.multiproject.basedir=../../ > That is what I meant to write :) > Thanks a lot You're welcomed :) Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: multiproject:site - POM outside main dir tree isn't included
> -Original Message- > From: Fabio Uechi [mailto:[EMAIL PROTECTED] > Sent: Tuesday, April 27, 2004 12:51 PM > To: maven maven > Subject: multiproject:site - POM outside main dir tree isn't included > > > > Hi, > > I'm using the multiproject plugin to generate my site. One of my > subprojects isn't in the same directory although it also extends > the master project.xml. > The problem is that whenever I try to invoke any multiproject > goal the reactor never includes this POM, only the others that > are under the main dir. > > I'm setting the property: > > maven.multiproject.includes=../../j2me-dev/WTK21/apps/efitness > -mobile/project.xml,**/project.xml > > But it still isn't working. I'm currently using maven-1.0-rc2 > and I have two multiproject-plugins installed (1.1 and 1.2). > Any help is apreciated! > My colleague from work had the same problem. I tried to track it down and it seems that everything goes well until the call is made to ant API and it is ant directory scanner which is not working properly with such patterns. I don't know if this is a feature or a bug. The Workaround is to set you maven.multiproject.includes=..\..\ and then reference your sub-projects from there. Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Query on current approach to integration tests
> -Original Message- > From: Tim Stephenson [mailto:[EMAIL PROTECTED] > Sent: Monday, April 26, 2004 1:29 PM > To: '[EMAIL PROTECTED]' > Subject: Query on current approach to integration tests > > > Hi, > > I notice that there have been a few changes to the project xsd (and > supporting implementation classes) around integration tests > sometime over > the last year when I have been away from maven for one reason > or another. > > I have an old problem around how to split out certain tests > (which I dub > 'integration tests') from the regular unit tests. There are 2 ways I > identify these tests: > > a) slow running tests > b) tests that require the project code to be deployed > before testing > begins (eg EJBs) > > I used to employ a modified version of the test plugin that > offered goals > like iutest:test and iutest:single, but unfortunately > developed this when > the test plugin was rapidly evolving so it quickly became > obsolete. Can > anyone suggest the preferred approach to solving this problem > now that the > pom support for the integration source directory is deprecated (and > partially removed) > > Thanks, Tim > The simplest solution is to create one more project for your iu tests. It can either use jar artifact of main project which you want to test or directly operate on sources of the main project. Then you are able to use all goals of test plugin. Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Configure Maven to work with local network drive and differen t jar names
> -Original Message- > From: Rahamim, Zvi (Zvi) ** CTR ** [mailto:[EMAIL PROTECTED] > Sent: Sunday, April 25, 2004 7:43 PM > To: Maven Users List > Subject: ZQ: Configure Maven to work with local network drive and > different jar names > > > Hi! > In my company the jars of the various projects are in a > network drive so that everybody can access them. > Each project has its own project directory, and under this > directory there is a directory for each version (in the > version directory there are all the files that relates to > this versions). > > For example, let's say that I have projects A and B (B uses A). > A has jar called aaa.jar. > A located at K:/Projects/A/ > B located at K:/Projects/B/ > > Can you tell me how to configure Maven to build project B? > > > Some more questions: > 1. I understood that I have to specify a specific jar name > (that doesn't have the expected format) in all the projects > that use A, right? (Why not put this information inside > project.xml that relates to project A?) Not sure if I follow. Maven promotes it's own standard way of declaring dependencies and organizing repositories of artifacts. If I understand you correctly your question is: can I use custom repository structure and custom way of declaring dependencies. At the time being there is nothing in maven which allows you to plug your own "strategy" for organizing repository. Although it will be probably possible (internally) in next generation of maven this is not something we would really like to see as there are obvious profits from using common standards. So at the moment either you use maven with "maven standard" and this works out of the box or you are on your own with the full power to do things as you want. But then the profits from using maven (if any) are not so appealing. Only way for making some things which are off the standard is: http://maven.apache.org/reference/user-guide.html#Overriding_Stated_Dependen cies > 2. Is there a way to use different file name than maven.xml? No. Why do you need to do this? > 3. Is there a way to 'overide' an existing goal (I know there > are ways to do things before and after using the pre and post goal) > Just try :) > > Thanks! Can you please avoid sending twice the same message (to both user & dev lists)? Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: HELP! - rc2 - resource exception on download
> -Original Message-
> From: Dan Washusen [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, April 07, 2004 11:54 PM
> To: Maven Users List
> Subject: Re: HELP! - rc2 - resource exception on download
>
>I found that upgrading to RC2 also caused me some issues. I just
>deleted (moved away) my ~/.maven directory and downloaded everything I
>needed again. It was anoying (because it took so long) but it all
>seemed to work again after that. At first I tried just deleteing the
>plugins directory but that wasn't enough...
Next time try to keep your local reposository in different place!
You can define its location in ${user.home}\build.properties
I myself use:
maven.repo.local=c:\\apps\\repository
Michal
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Using Maven on a very large integration project - how far can Maven go?
> -Original Message- > From: Rafal Krzewski [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 08, 2004 9:54 AM > To: Maven Users List > Subject: Re: Using Maven on a very large integration project - how far > can Maven go? > > > Tomasz Pik wrote: > > > if war plugin finds 'war' dependency then un-war it and > merge content > > of dependency war into created war. > > At least web.xml files should be merged together, probably more > > descriptor files too - but this may be done as postGoals. > > I don't think that merging web.xml or other files is a good idea. The > logic for that has a good chance of becoming obscure and fragile. > I would just make the dependant project files override the > dependencies > files. Simpler & more predictable... > > R. I agree in 100%. That's what I did in my version. For the people which were intersted in this functinality: I won't manage to push it to CVS before holidays (no time) I pratically finshed zip plugin which pacakes all project resources into zip files and merges the content of multiple zips (declared as dependencies_. I just gave it to somebody for testing (I still have some problems with resource filtering) and when I'll be sure that it works I can add it to CVS. Anybody opposes to add this funcionality to RC3? With this plugin I am able(will be able) to keep in local repositoriy zip files which contains even such artifacts like JRE/JDKs, Java Service Wrapper files etc and only compose those artifacts for particual application. (To Jason)I belive it will be easy to construct plexus runtime using this techniue. Pratically no java nor jelly code is needed. I mean just something like: plexus plexus-runtime 1.0 zip plexus plexus-startup-scripts-win32 1.0 zip plexus plexus-jws-win32 1.0 zip jre jre 1.4.2 zip . Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Using Maven on a very large integration project - how far can Maven go?
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Monday, April 05, 2004 3:10 PM > To: Maven Users List > Subject: Re: Using Maven on a very large integration project - how far > can Maven go? > > > > That is really cool. Very useful. Are you going to push through the > zip plugin and war plugin changes? I haven't been thinking about that but if somebody will find it useful I can certainly do that. I should not have any problems with creating zip plugin. It's bit more difficult with war plugin but doable. The idea is that when war plugins finds any dependency of type "war" it should un-war it (unzip :) and use files which were stored there as sources for building new war file. I have it working but it's rather a quick hack then "release quality". But I can try to improve it if somebody will be interested. Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Using Maven on a very large integration project - how far can Maven go?
> -Original Message- > From: Michael MATTOX [mailto:[EMAIL PROTECTED] > Sent: Monday, April 05, 2004 11:59 AM > To: [EMAIL PROTECTED]; Maven Users List > Subject: RE: Using Maven on a very large integration project - how far > can Maven go? > > > > I think your overall approch is on target. One of the > things I have found > > easier when deploying to containers is to have Tomcat as > part of CVS.. It > > gives you a lot more control over what the Tomcat > environment looks like, > > isn't too large, and reduces variables. > > I agree in principle. The problem is it's not practical to > put WebSphere or > Oracle in CVS. So what I was thinking was to divide the > containers into two > categories: > > - versioned in CVS - for unstable, lightweight containers > only. For example > tomcat. > > - an install procedure using official releases. This would > be for Oracle, > MySQL, WebSphere. > > Tomcat can fall into either category, and I prefer the > second. But I'm open > to suggestions. > > > Also, as far as the merging of jars, anything you can do in Ant, > > you can do > > in Maven, as Maven supports all ant tasks. Here is an article > > that gives a > > simple example of calling the task from Ant in Maven: > > http://www.onjava.com/pub/a/onjava/2004/03/17/maven.html. > > This is a worst case, call the ANT target. But with Maven's > Jelly scripts I > wasn't sure if it'd be better to do something with ANT or Jelly. > I am using quite different technique. I keep Tomcat and such as zips in my maven repository. For example in case of Tomcat I have removed most of the files and I keep only those files which are really needed to run it in a zip file in local repository. Then I have POM fragments like: foo foo-webapp 1.0 war foo foo-configuration-for-node-X 1.0 zip tomcat tomcat 4.1.27 zip tomcat tomact-admin 4.1.27 war and plugins which are creating application which are a merger of tomcat zip/wars (possibly many wars)/zip with configuration settings. As the result I get another zip (ready to use application) which is zipped and installed in my local repository. Using this technique I am for example easily enable to use different version of tomcat (just need to edit my POM to change it) or have many configuration (for many customers) of the same application. But I am _always_ using local repository for keeping and exchaing artifacts between projects. Even artifacts like tomcat (zip) or configuration files. I have created maven zip plugin which puts to zip archive all the files declared as resources in POM and which is also able to merge many zips into one. I am also using my own version of war plugin in which I can declare dependencies on other wars and just replace some configuration files. So I have one base war file and couple of its mutations for various environments: for testing (e.g. against different databases), for various production environment (in my case we use the same wars with different configuration setting for different customers). Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Réf. : elementary problem with dependency.
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Friday, April 02, 2004 11:50 AM > To: [EMAIL PROTECTED] > Subject: Réf. : elementary problem with dependency. > > > > Hi > > Shouldn't the module-ejb be a > module-ejb > ? > > I think when it's an the type is ignored and supposed to be jar. > > Julien > > Sure he should use . was deprecated some time ago. Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: like ant unless
> -Original Message- > From: Marcin Gurbisz [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 01, 2004 1:52 PM > To: Maven Users List > Subject: like ant unless > > > Hi > > Have maven something like conditional goal execution? Like > "unless" in > ant target. > You can directly use all ant constructs like "unless" but in maven you can also use all the functions which are avilable available in jelly so you can do things like: (conditinal call) or (conditinal processing of the goal) You might want to ready jelly tutorial (it's quite similar to JSP 2.0 but bit more powerful) pzdr Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Dependency - If version is not specified, should it consider '-' or not?
> -Original Message- > From: Veerasamy, Thirumalai (Cognizant) > [mailto:[EMAIL PROTECTED] > Sent: Monday, March 29, 2004 2:36 PM > To: Maven Users List > Subject: Dependency - If version is not specified, should it consider > '-' or not? > > > Hi, > > I specify a dependency like given below. > > > group > artifact > > > Though I didn't specify a version for that file it still expects as > group/group-artifact-.jar. Is this the expected behaviour? Yes it is expected behaviour. > Shouldn't it > ignore '-' if version is not specified. > No! all artifacts in the repository must be versioned. Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: clover generation problem
try to use: maven.junit.fork=true Michal > -Original Message- > From: ZHU Beiting [mailto:[EMAIL PROTECTED] > Sent: Friday, March 19, 2004 10:50 AM > To: 'Maven Users List' > Subject: clover generation problem > > > Hello, > > I would like to use maven-clover-plugin to generate the > clover report for > the quality of my JUnit tests. After running I got a result > very strange, > all of the results is 0%. > > Is there any one encountered this case also? Could you please > give me some > idea? > > Thanks, > Beiting. > > - > 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: Maven war plugin
What do you want to exclude: java classes or "web resources"?
"war" plugin uses "java" plugin for compilation of java sources and for
exlusion of java classes you can use properties of that plugin.
Michal
> -Original Message-
> From: Nicolas Cazottes [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, March 17, 2004 12:14 PM
> To: [EMAIL PROTECTED]
> Subject: Maven war plugin
>
>
> Hello,
>
> Currently working on a project with maven, I needed to use the war
> plugin with the ${maven.war.src.excludes} property in order to build a
> packaged Web App. After a while without success, I checked
> the source code
> of the
> war jelly tag and found that the option I wanted to use is
> not used (or
> implemented ?) in the plugin war:war goal.
> Is there a reason that I am missing for this behaviour ?
>
> Thanks,
>
> Nicolas Cazottes
>
>
> -
> 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: multiproject and clean:clean
> -Original Message- > From: Jens Zastrow [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 02, 2004 3:43 PM > To: Maven Users List > Subject: multiproject and clean:clean > > > I have 2 subprojects > > > > A, B > > > > B depends on A (has a dependency) > > > > If i invoke multiproject:clean i get the error that project > A.jar cannot be dowloaded. > > This might be correct for a normal build but for a simple clean not. > > > > How can I disable the dependency-check during "multiproject:clean". > You cannot. Maven checks if all dependencies are satisfied before lettting you to execute any goal. You might call it a bug or feature.. What you can try is: maven multiproject:goal -Dgoal=clean,jar:install (not 100% sure about the syntax) Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: multiproject:artifact, SNAPSHOT dependencies and the reposito ry
Ben: I think that such problem exists and it is certainly not limited to ibiblio only. I have the same exact bug when I am working with intranet web server. I don't know if this is problem of maven it self, web server caching, proxy server caching etc. I am too busy to look into it at the moment :( I was forced (lack of time to fix it) to stop working with SNAPSHOTs. Michal > -Original Message- > From: Ben Walding [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 02, 2004 4:11 PM > To: Maven Users List > Subject: Re: multiproject:artifact, SNAPSHOT dependencies and the > reposito ry > > > Nope, Maven does check the date - it uses the http protocol to only > download as required. However I think there might be some > issues in it > - possibly even in the ibiblio web server / dates on the > server (see my > earlier email today) > > I'll take a further look when I code up the snapshot > downloader for the > maven-proxy. > > Kalaveshi, Adrian wrote: > > >I also don't believe that Maven checks to see which SNAPSHOT > is newer. > >Maven seems to always download it -- even if they are > identical. Anyone > >have a definitive answer for this? I'm using 1.0-rc1. > > > >Using the "-o" option isn't sufficient enough. I'd like to avoid > >downloading SNAPSHOT jars of my internal projects (or, I > should say, I'd > >like to avoid overwriting the newer SNAPSHOT jar that exists > in my local > >repository) but, at the same time, I need to have access to > everything else > >in the repository. > > > >-adrian- > > > >-Original Message- > >From: Jörn Gebhardt [mailto:[EMAIL PROTECTED] > >Sent: Tuesday, March 02, 2004 1:19 AM > >To: Maven Users List > >Subject: AW: multiproject:artifact, SNAPSHOT dependencies and the > >reposito ry > > > > > >Hi, > > > >That's strange. We have exactly the same problem that Adrian > described. I > >believe that Maven doesn't check any dates when resolving SHNAPSHOT > >dependencies, but just downloads the SNAPSHOT jar from the > remote repository > >if it is there. > > > >I've posted a similar message some weeks ago and was advised > to used the -o > >(offline) option of Maven (e.g. maven -o jar) to suppress > the download from > >the remote server. Alternatively, you can set a property (I > don't remember > >the property name, but it's documented somewhere...) in your local > >build.properties to switch to the offline mode. > > > >Jörn > > > > > > > >>-Ursprüngliche Nachricht- > >>Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > >>Gesendet: Dienstag, 2. März 2004 04:20 > >>An: Maven Users List > >>Betreff: Re: multiproject:artifact, SNAPSHOT dependencies and the > >>repository > >> > >> > >>"Kalaveshi, Adrian" <[EMAIL PROTECTED]> wrote on > 02/03/2004 > >>08:09:36 AM: > >> > >> > >> > >>>Greetings -- > >>> > >>>Is there a best practices document describing maven's role in a > >>> > >>> > >>multiproject > >> > >> > >>>environment? > >>> > >>>One of the problems I'm currently trying to tackle is this: > >>> > >>>- internal components have dependencies to SNAPSHOT > >>> > >>> > >>versions of other > >> > >> > >>>internal components. > >>>- after each project is compiled, it's SNAPSHOT artifact is > >>> > >>> > >>created and > >> > >> > >>>'installed' to the local repository (for use by other projects) > >>> > >>> > >>We have exactly this. > >> > >> > >> > >>>- when the next project is compiled, it's dependencies are > >>> > >>> > >>downloaded > >>from > >> > >> > >>>the repository (overwriting the SNAPSHOT artifact that was > >>> > >>> > >>created in > >>the > >> > >> > >>>previous line item) > >>> > >>> > >>This doesn't happen for us. We never get a download as our > >>local SNAPSHOT > >>is newer than the one in the remote repo. > >> > >>-- > >>dIon Gillard, Multitask Consulting > >> > >> > >> > > > >- > >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: zip and classpath
Yep zips are treathed differently from the jars.
And Oracle naming convention for jdbc driver is second to none in its
stupidity ( 'classes12.zip' wtf !!)
I usually keep oracle jdbc driver in
${repo.root}/oracle/jars/oracle-jdbc-driver-12.jar
so I declare the appropriate dependency like:
oracle
oracle-jdbc-driver
jar
12
Michal
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Monday, March 01, 2004 11:41 AM
> To: [EMAIL PROTECTED]
> Subject: zip and classpath
>
>
>
> I am using maven candidate release rc1, I have a strange
> behaviour, when
> building my application. In the project .xml I have specified
> a zip file
> namely the Oracle classes in the dependancy part,
>
> something like that
>
>
> oracle
> classes12
> zip
> 1.0.0
>
>
> now when I am doing the build I cannot see that entry in the generated
> classpath, and therefore the build fails. Is there something
> I am doing
> wrong, and are the zip files treathed differently from the jars ?
>
> Any help will be welcome.
>
> Best Regards
>
> Michele
>
>
> This e-mail, including attachments, is intended for the person(s) or
> company named and may contain confidential and/or legally privileged
> information. Unauthorized disclosure, copying or use of this
> information
> may be unlawful and is prohibited. If you are not the
> intended recipient,
> please delete this message and notify the sender
>
>
>
>
> -
> 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: Depenceny version..
> -Original Message- > From: Maczka Michal [mailto:[EMAIL PROTECTED] > Sent: Monday, March 01, 2004 10:58 AM > To: 'Maven Users List' > Subject: RE: Depenceny version.. > > > > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > Sent: Monday, March 01, 2004 10:29 AM > > To: [EMAIL PROTECTED] > > Subject: RE: Depenceny version.. > > > > > > Hi, > > > > > -Original Message- > > > From: ext John Casey [mailto:[EMAIL PROTECTED] > > > > > The reason maven doesn't squawk at this is that it > > > doesn't check for > > > XML validity when parsing... > > > > Is this excpected to change in future releases? A non > > validating project.xml already was the source of some weird > > problems. Is the schema somewhere available online, so that > > you can define a schema location for it, which is public for all? > > > > Also, would it make sense to have a schema for maven.xml, too? > > > > Br, > > _ __ _ _ > > > > I doubt if it will be possible to validate POM using XML Schema. > The thing is that there is such thing like "POM inheritence" > and some mandatory tags can be inherited from parent project. > > It shouldn't be that hard to write our own POM validator in Java. > It even makes more sense then using XML based technlogies and POM > does't need. > > > Michal > I haven't finshed the last sententece :) In the last sentence I meant that POM doesn't need to be read from XML. It can be read from db, file produuced by java serialization mechanism etc. Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Depenceny version..
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Monday, March 01, 2004 10:29 AM > To: [EMAIL PROTECTED] > Subject: RE: Depenceny version.. > > > Hi, > > > -Original Message- > > From: ext John Casey [mailto:[EMAIL PROTECTED] > > > The reason maven doesn't squawk at this is that it > > doesn't check for > > XML validity when parsing... > > Is this excpected to change in future releases? A non > validating project.xml already was the source of some weird > problems. Is the schema somewhere available online, so that > you can define a schema location for it, which is public for all? > > Also, would it make sense to have a schema for maven.xml, too? > > Br, > _ __ _ _ > I doubt if it will be possible to validate POM using XML Schema. The thing is that there is such thing like "POM inheritence" and some mandatory tags can be inherited from parent project. It shouldn't be that hard to write our own POM validator in Java. It even makes more sense then using XML based technlogies and POM does't need. Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: multiproject:artifact
-Original Message- From: Daniel Flesner [mailto:[EMAIL PROTECTED] Sent: Friday, February 20, 2004 4:04 AM To: Maven Users List Subject: multiproject:artifact >we use multiproject:artifact to build multiple components. but, for our ejb's we need to build the ejb and the client jars. >i tried adding maven.multiproject.type=ejb-client but the build errors trying to build target ejb-client:ejb-client. if you change the type to ejb it just >builds the bean jar. any workarounds here? why doesn't multiproject:artifact just build the default goal that's in maven.xml? becouse most of the project do not have it and there is no reason for that. What you can do is to use the following layout: ejb ejb-client ejb-client will have maven.multiproject.type=jar and ../ejb/src/main/java So basically the same java sources will shared by both projects and ejb-client.type = "jar" Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
