test plugin has some problem
plugin.jelly in test plugin: this snippet has some problem. to avoid using xerces, setting maven.junit.fork=yes doesn't help. is there another way to avoid using xerces?
Re: Getting plugin version
How can I use different plugin version? I want to override some plugin for our company, but don't know how to. or, please remove xml parser dependency from test plugin. it is useless. let the user select parser!! - Original Message - From: "Brett Porter" <[EMAIL PROTECTED]> To: "Maven Users List" <[EMAIL PROTECTED]> Sent: Tuesday, September 14, 2004 10:23 PM Subject: Re: Getting plugin version > maven --info > > > On Tue, 14 Sep 2004 09:17:20 -0400, Eric Giguere > <[EMAIL PROTECTED]> wrote: > > Hi all > > > > Anybody knows if there is a way to print out on the console the active > > version of a plugin? > > Could usefull when environment checks are required. Ex.: one of my team > > members have a problem building, first check to do the version of the > > plugin used to see if its up to date. > > > > thx > > Eric. > > > > - > > 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: xerces
How's it going? would xml parser setting be removed? answer plz - Original Message - From: "Pak, Young-rok" <[EMAIL PROTECTED]> To: "Maven Users List" <[EMAIL PROTECTED]>; "Brett Porter" <[EMAIL PROTECTED]> Sent: Thursday, October 28, 2004 10:17 AM Subject: Re: xerces > > I'm interested in why you need MS949 for project.xml. The reason I ask > > is that we intend to switch to a smaller, faster XML parser in Maven > > 1.1, however it is likely to support fewer encodings and xml features > > - but still supports everything required to correctly operate Maven > > that we have found to date. > > > > If you could explain the need for this encoding, and whether there are > > any alternatives, that would be great. > > > I'm Korean, and in Korea, MS Windows Korean version is most popular OS. Because this > OS's default encoding is MS949, most of source codes and documents is written in > MS949 encoding. Of course, it's not impossible to change encoding to UTF-8, but it > is expensive. In J2EE platform, there are many points that might raise encoding > conflict problem and we have verified them for MS949 encodings, but not for UTF-8 > and other encodings. > There is EUC-KR encoding for Korean and xerces support it. but it cannot support all > korean characters. So we need support for MS949 encoding. > > Sun changed their JVM's default parser from Crimson to Xerces in JDK 5.0. But > Instead of using xerces directly, they fixed some features of xerces. So, using JDK > 5.0, all java encodings are supported. So I want to use this, but to use this, I > should fix maven execution script file. > > I think it will be good to switch to lightweight parser, but user should be able to > select their own parser. > > >
Re: xerces
> I'm interested in why you need MS949 for project.xml. The reason I ask > is that we intend to switch to a smaller, faster XML parser in Maven > 1.1, however it is likely to support fewer encodings and xml features > - but still supports everything required to correctly operate Maven > that we have found to date. > > If you could explain the need for this encoding, and whether there are > any alternatives, that would be great. I'm Korean, and in Korea, MS Windows Korean version is most popular OS. Because this OS's default encoding is MS949, most of source codes and documents is written in MS949 encoding. Of course, it's not impossible to change encoding to UTF-8, but it is expensive. In J2EE platform, there are many points that might raise encoding conflict problem and we have verified them for MS949 encodings, but not for UTF-8 and other encodings. There is EUC-KR encoding for Korean and xerces support it. but it cannot support all korean characters. So we need support for MS949 encoding. Sun changed their JVM's default parser from Crimson to Xerces in JDK 5.0. But Instead of using xerces directly, they fixed some features of xerces. So, using JDK 5.0, all java encodings are supported. So I want to use this, but to use this, I should fix maven execution script file. I think it will be good to switch to lightweight parser, but user should be able to select their own parser.
Re: xerces
> The reason is simple - the crimson parser bundled with the JDK's through > 1.4.2(?) is complete crap. Additionally, even older JDK's don't have a > parser bundled, which means you'd have to create multiple maven distros > (one for parser-bundled JDKs and another which accounted for the xml > parser). You're welcome to try to change the parser used by maven of > course, but don't expect much in the way of support. These libraries are > found in $MAVEN_HOME/lib/endorsed, and I believe they may be referenced > specifically in the forehead.conf file in $MAVEN_HOME/bin (not sure > about that, though). I think it's good for maven to offer XML parser library in $MAVEN_HOME/lib/endorsed, but it's not good to specifiy XML parser in maven execution script. Current maven execution script includes this lines: -Djavax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl -Djavax.xml.parsers.DocumentBuilderFactory=org.apache.xerces.jaxp.DocumentBuilderFactoryImpl This is unnecessary. Only containing xerces.jar, you can specify default XML parser as Xerces. As you know, JVM's parser factories find parser class name in META-INF/services/javax.xml.parsers.SAXParserFactory and META-INF/services/javax.xml.parsers.DocumentBuilderFactory. If that two lines would be removed in the maven execution script, I can change XML parser by just changing xerces.jar with other library. > One final thought: leaving the parser choice up to the user is the right > thing to do when you're developing an application component which will > run in some java context outside its own. However, this is an > unnecessary and even undesirable level of flexibility for a standalone > tool like maven. It only serves to make installation, configuration and > [especially] support more complex. Current Xerces cannot parse some encodings like MS949. so if I create project.xml with MS949 encoding, maven doesn't work. Some test including parsing MS949 XML document doesn't work, too. There is some alternations like JAXP 1.3(containing xerces with some fixes), but I must modify maven execution script to use them. So I suggest that the two lines be removed from maven execution script.
Re: xerces
it helps in some cases, but I still want to change xml parser for maven. I want to use JVM's default parser. why maven specifies XML Parser? I think this is bad. users must be able to choose their own parser without modifying maven script and classpath. - Original Message - From: "John Casey" <[EMAIL PROTECTED]> To: "Maven Users List" <[EMAIL PROTECTED]> Sent: Tuesday, October 26, 2004 11:40 PM Subject: Re: xerces > Yes, maven has an extdir that includes xerces-2.4.0 and xml-apis-1.0-b2. > > You should try specifying 'maven.compile.fork=true' in your > project.properties to see whether this helps. It should cause the javac > execution to take place in a new process which is free of the maven > version of xerces et al. > > -j > > Stéphane Nicoll wrote: > > Hello list, > > > > In one of my project I use namely xerces-2.6.2, xalan-2.1.0 and xml-apis-2.0.0. It > > used to be an ant project which is compiling fine (SUN JDK 1.4.2). Now I moved to > > a maven project with exactly the same dependencies (I checked 3 times and even > > copy the lib from the ant project directly in my maven repo), I still have the > > same issue: > > > > isXMLName(java.lang.String) in org.apache.xerces.dom.CoreDocumentImpl cannot be > > applied to (java.lang.String,boolean) > > > > Having checked the API, it seems to be a change since xerces2 which I have. > > Putting my dependencies in IDEA and compiling just work fine, as my ant project. > > Is Maven using a given xerces version which is overiding my dependency somehow? > > > > Regards, > > Stéphane > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED]
How about using groovy intead of jelly?
jelly is good scripting language but still restricted than real script language. groovy-ant scripting can overcome such restriction. instead of maven.xml, how about using maven.groovy?
Re: how to deploy file to repository without filename modified?
thanks for replies. they really helped me. but still have problem. first, modifying web.xml is not good as much as modifying JSP files. because about twenty projects use that taglib, so if taglib changed, I must change twenty web.xml. in fact, it isn't difficult job, but it seems bad job. taglib will be developed day after day, and other web developers want to know just one name for one product. notifying difference of both versions is easier than changing filename because all products are in-company project. second, putting tld into jar seems good idea. and it solved my case. but one jar may need two or more tld files like JSTL or Struts. how can I solve a case like these? third, I have another requirement that need simple copying deployment. our web projects have some categories, and in same category projects have common web resources like jsp and html. so we extract that common resources and make a seperated project. for example, project A, B, C are in same category CAT1, 4 project are needed: common-CAT1, CAT1-A, CAT1-B, CAT1-C. at build time, common-CAT1's resources should be copied to CAT1-A, CAT1-B, CAT1-C. of source all associated project must be checked out to local workspace. we have used Ant for this job, and I want to use Maven for this. I think if I can deploy common-CAT1 in webapp form, CAT1-A can use it as dependency. making war for this job is not good because it should do unnecessary job. if I could build common-CAT1 using war:webapp and deploy the built webapp directory, it'll be great. how do you think about this?
Re: how to deploy file to repository without filename modified?
I want to deploy some tld files(JSP Tag Library Descriptor) to repository and use that as dependencies in other project. for example, the project 'mytag' produces mytag.tld and mytag.jar, and other web project myweb uses both file. I want to deploy both files using jar:deploy with some postGoal definition in maven.xml. Why the name of tld files should not be changed is that their file name will be used in JSP page like this: <%@ taglib uri="/WEB-INF/tlds/mytag.tld" prefix="mytag" %> mytag-1.0.tld seems not good name for tld file. and the name should not change even if it versions up. - Original Message - From: "Brett Porter" <[EMAIL PROTECTED]> To: "Maven Users List" <[EMAIL PROTECTED]> Sent: Wednesday, September 22, 2004 8:20 PM Subject: Re: how to deploy file to repository without filename modified? > This is intentionally not supported. Artifacts need versions in the > repository, especially with new features coming in Maven. > > What problems will this cause you? > > - Brett > > On Wed, 22 Sep 2004 20:10:17 +0900, Pak, Young-rok > <[EMAIL PROTECTED]> wrote: > > I want to deploy some files to repository without modifying filename when > > deploying jar. for example, there is file to deploy in my project like this: > > > > src/tld/mytag.tld > > > > and, I want to deploy to my repository like this: > > > > mygroup/tlds/mytag.tld > > > > so, I tried to use maven.xml like this: > > > > > > > > > > > > but, failed. mytag.tld copied to: > > > > mygroup/tlds/myproject-1.0.tld > > > > this is not what I wanted. and found no other way. how can I do that? if there is > > no way to do that, I think artifact plugin must be extended to support that. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
how to deploy file to repository without filename modified?
I want to deploy some files to repository without modifying filename when deploying jar. for example, there is file to deploy in my project like this: src/tld/mytag.tld and, I want to deploy to my repository like this: mygroup/tlds/mytag.tld so, I tried to use maven.xml like this: but, failed. mytag.tld copied to: mygroup/tlds/myproject-1.0.tld this is not what I wanted. and found no other way. how can I do that? if there is no way to do that, I think artifact plugin must be extended to support that.
Re: SNAPSHOT dependencies doesn't work with specifying jar file name.
Do you mean this is already registered as JIRA issue and will be fixed? or should I submit this issue to JIRA? I've looked for this in JIRA, but couldn't find. If this is already registered, would you tell me the JIRA key of this issue? - Original Message - From: "Brett Porter" <[EMAIL PROTECTED]> To: "Maven Users List" <[EMAIL PROTECTED]> Sent: Wednesday, September 22, 2004 7:35 PM Subject: Re: SNAPSHOT dependencies doesn't work with specifying jar file name. > I think this is a bug already in JIRA: it checks the filename for > SNAPSHOT, where it should check both version and the filename. > > > On Wed, 22 Sep 2004 11:09:37 +0200, [EMAIL PROTECTED] > <[EMAIL PROTECTED]> wrote: > > try to use only > > > > > > ibatis > > ibatis-nhn > > SNAPSHOT > > > > true > > > > > > > > this should work, double chech that this component that you are bundling > > must have in its pom.currentVersion SNAPSHOT as well > > > > Regards > > > > Michele > > > > |-+> > > | | "Pak, Young-rok" | > > | | <[EMAIL PROTECTED]| > > | | o.co.kr> | > > | || > > | || > > | | 22/09/2004 10:54 | > > | | Please respond to| > > | | "Maven Users | > > | | List"| > > | || > > |-+> > > > > >--| > > | > > | > > | > > | > > | > > | > > | > > | > > | > > | > > |To: "Maven Users List" <[EMAIL > > PROTECTED]> | > > |cc: (bcc: Michele > > Forte/SwissRe) | > > |bcc:Michele Forte/SwissRe > > | > > |Subject:SNAPSHOT dependencies > > doesn't work with specifying jar file name. | > > > > >--| > > > > > > > > > > I defined dependecy like this: > > > > ibatis > > ibatis-nhn > > SNAPSHOT > > ibatis-2.jar > > jar > > > > true > > > > > > > > I want maven to check the timestamp and redownload if ibatis-2.jar in > > remote repository is newer, but it doesn't work. maven just tried to > > compile with current ibatis-2.jar in local repository. how can I make it > > work as I wanted? is there another way? > > > > > > 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] >
SNAPSHOT dependencies doesn't work with specifying jar file name.
I defined dependecy like this: ibatis ibatis-nhn SNAPSHOT ibatis-2.jar jar true I want maven to check the timestamp and redownload if ibatis-2.jar in remote repository is newer, but it doesn't work. maven just tried to compile with current ibatis-2.jar in local repository. how can I make it work as I wanted? is there another way?
can I use pom in repository to extend?
after deploying maven-based project, jar and pom is deployed to repository. can I use that pom file to extend in other project?
