Re: [lang] Junit 3.8.1 vs. 3.8.2
... maven1 repository at ibiblio has some rewrite rules so if there's no requested file, maven2 repository is used (and those rules translate between repository layouts). Or, even more, maven2 repo is always used, I'm not 100% sure. The maven 2 repository is always used (the directory listing in the m1 repo is completely outdated). To find an artifact you can use http://www.mvnrepository.com/ http://www.mvnrepository.com/artifact/junit/junit Arnaud
Re: [lang] Junit 3.8.1 vs. 3.8.2
... Thanks - I'd thought the directory listing was being mod_rewritten too. Hen No. (I'm not sure that it is possible but if an expert want to help us ... ;-) .) Arnaud
Re: [vfs] split of vfs
In M1 there's no transitive dependencies, thus your users will have to define each dependency one by one. But to improve the conversion between m1 and m2 poms for the repository, if you deploy VFS with m1 you can add the following setting : http://maven.apache.org/maven-1.x/using/bestpractices.html#Getting_ready_for_Maven_2 Arnaud On 7/27/06, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi Jörg! Well, therefore I would not split it at all. If you feel that the core API is right, just release 1.0 with all stuff left outside, that might cause licensing trouble. You may release 1.1 later on easily with the stuff included as soon as you have answers. Not only licensing troubles, also the thing with snapshot/not-released dependencies. bz2 and tar hurts if they are not at least easily pluggable, sure, I can copy compress (its not that big) to VFSs codebase (to a different namespace), then, only smb and webdav is missing. Its an option, but I like the snapshot jar way more. As marked out in the other thread, marking dependencies as optional is perfectly valid. Uhm ... this is not possible with maven 1, is it? Could you give me a hint please. Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release commons-jelly-tags-interaction 1.1
Do you plan to deploy the sources with the new source plugin ? http://maven.apache.org/maven-1.x/plugins/source/ Arnaud On 6/21/06, Dion Gillard [EMAIL PROTECTED] wrote: Ah. Sounds like something we should be fixing if that's the case. On 6/21/06, Paul Libbrecht [EMAIL PROTECTED] wrote: Maybe... I'll work on this tonight local time (in about 14 hours). The problem is that maven dist calls the maven dist of jelly which is quite wrong, I think... and I did not want to touch this yet. If it sounds appropriate and someone can check my candidate sources I could try this tonight before tagging it would only affect, probably, the maven.xml in jelly/jelly-tags. paul Dion Gillard wrote: Paul can we post the source/binary distribution release after getting the jar out? On 6/20/06, Paul Libbrecht [EMAIL PROTECTED] wrote: Rahul Akolkar wrote: Regardless of what Jelly has been doing in the past, IMO its a good idea to have source distributions for any release, given which one would be able to (atleast after meeting certain pre-requisites) effectively reproduce the release binaries. Why don't Jelly taglibs have accompanying source distros? As a general wish, I only agree. In this case both limit in time and the fact that this tag-library is exactly made of one class tend me to not do so. Note we had a similar situation in Jakarta Taglibs which AFAICT has since been remedied. Also, a gentle reminder to please tag SVN (as previous Jelly releases have done). Of course tagging was planned. Do you mean I should tag RC1 as well ? Since I've not participated in the discussion so far, and wasn't around to bring this up earlier for the last three days when the plan (below) was posted, I will vote 0. I will also encourage you to leave votes open for atleast 72 hours (instead of 36). The fact that I sent this wish already long ago, with less clarity indeed, pushes me here. And also, the fact that maven plugin release is waiting. paul Thank you for your time towards this release. -Rahul thank you in advance. paul Paul Libbrecht wrote: Here's the plan: - all issues with this tag-libs are cleared - no further changes are needed for the release... and almost no risk of concurrent change exist (hence no branch is needed). - the release shall, as with most jelly-tag-libraries, only produce jar files to be consumed from the maven repo at ibiblio and the repo at apache. No source or binary distribution will be made. - once the vote passed, I will simply update changes.xml and project.xml, tag the files, upload the jar to the Apache, submit a jar upload to iblio's repo. I have assembled the following release candidates... - a site with RC1 version tag: http://people.apache.org/~polx/tmp/jelly-tags-interaction-rc1/ - a jar which is the sole outcome of this subproject: http://people.apache.org/~polx/tmp/commons-jelly-tags-interaction-1.1-RC1.jar -- http://www.multitask.com.au/people/dion/ Chuck Norris sleeps with a night light. Not because Chuck Norris is afraid of the dark, but because the dark is afraid of Chuck Norris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] Upgrade to dom4j 1.6.1 ?
In maven 1.1 beta 3 we'll upgrade to dom4j 1.6.2 (not yet released) which fixes a problem with xml entities. Thus we are particularly in favor to upgrade your dependency in Jelly. It will limit incompabilities between us. arnaud On 6/2/06, Paul Libbrecht [EMAIL PROTECTED] wrote: I please beg another round of review... or I'll interprete the silence as no bother and will do... paul Hans Gilde wrote: +0 If the unit tests pass, I'm inclined to say that the latest version should be used. But I have not tried it. -Original Message- From: Paul Libbrecht [mailto:[EMAIL PROTECTED] Sent: Saturday, May 13, 2006 5:06 PM To: Jakarta Commons Developers List Subject: [jelly] Upgrade to dom4j 1.6.1 ? Hello Jellyers, After my two test fixes, which had almost nothing to do with dom4j... I seem to be happily running everything with dom4j 1.6.1. Can anyone confirm me this ? It's quite radical but it'd help in many other places. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] [vote] Release commons-jelly-tags-interaction 1.1
Hi guys, Will you release it ? Arnaud On 5/17/06, peter royal [EMAIL PROTECTED] wrote: The story seems quite simple so I thought I'd just ask for a vote sorry if too stressed. The interaction jelly tag-library is now ready for release 1.1. It has been recently boosted with a finer control on auto-completion, and maven console plugin is using it successfully. Thanks to give it a try* and provide a vote. This vote will last till Friday 12:00 GMT. [ ] +1 yes let's release it [X] +0 maybe [ ] -0 seems not ready [ ] -1 no, don't! I support the release, but don't have time to actually test it. -pete -- [EMAIL PROTECTED] - http://fotap.org/~osi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira?
Another advantage it's the possibility to customize your dashboard(s) with a lot of portlets. You can define what you want to see : the issues open, your votes, ... It's really useful for developers like us. Cheers. Arnaud (Maven's team) On 4/26/06, Henri Yandell [EMAIL PROTECTED] wrote: On 4/25/06, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! I know Jelly are on Jira already, and Struts have just moved over to Jira. Wondering what the view is nowadays on Commons moving to Jira? I am -1 on moving to jira. Reason for mentioning Struts above was that I remembered that one of the -ve votes a few years ago on moving to Jira was from Martin and I thought some other Struts guys; thus the email to see if the consensus had moved. I'm +1 in favour of Jira, but not religious about it. I dont understand why we - the open source developers and our users - should help testing a commercial application. This is a common reason to not use Jira. From an ASF point of view, it's a bit weak I think. The ASF encourages companies to build commercial products on top of open-source software so using things like Jira is kind-of using our own dog-food. If Atlassin just offered Apache a licence, then it would be the kind of thing that we wouldnt accept. However if they offer it to everyone, then it's much the same kind of thing we push for at the JCP - open-source projects shouldn't be locked out due to lack of money. Also I dont understand whats the great benefit for us - compared to bugzilla - that we act as a marketing plattform for jira. Major advantages of Jira: * Project based administration - rather than central administration. * Visualization is much better - release management really shouldn't be maintaining a list of issues in wiki, it should be handled in the issue tracker. Well, you think it should after doing things in Jira anyway :) * Search sharing. There are probably other ones for other people, but for me I think it improves the speed in which we can identify open issues, which versions they're for etc. I'm getting better with Bugzilla now, but it still feel clunky. Sorry if I completely missed the point. Do not hesitate to correct me. Nope, you got the point. Just me wondering if consensus had moved to Jira now that Struts (well Martin was the one I was IMing) are Jira fans. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pool] Announcing Release Candidate 2 for Pool 1.3
The last snapshot of the distribution plugin makes the necessary arrangements http://maven.apache.org/maven-1.x/plugins/dist/changes-report.html#Release1_7-SNAPSHOT MPDIST-27, MPDIST-28 were done by Phil for another component. Arnaud On 3/24/06, Oleg Kalnichevski [EMAIL PROTECTED] wrote: robert burrell donkin wrote: On Thu, 2006-03-23 at 14:12 -0800, Martin Cooper wrote: On 3/23/06, robert burrell donkin [EMAIL PROTECTED] wrote: On Thu, 2006-03-23 at 15:45 -0500, Sandy McArthur wrote: On 3/23/06, Oliver Heger [EMAIL PROTECTED] wrote: snip - LICENSE.txt and NOTICE.txt have unix style line endings in the zips. (This is not a problem for me, but was cause for some discussions in the past.) I'm on a mac os x box and unix style would be the default. How do other projects solve this other than building on win32? not sure if it can be done in maven 1. anyone know? Well, Maven can invoke Ant, so you could use this: http://ant.apache.org/manual/CoreTasks/fixcrlf.html good point :) how easy would it be to persuade maven to use different fixes before rolling the zip and the tar? - robert Robert, We had to implement something similar for [HttpClient] a while ago. You might find maven.xml from [HttpClient] package a good starting point http://svn.apache.org/repos/asf/jakarta/commons/proper/httpclient/trunk/maven.xml Oleg - 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: [configuration] please use optional in POM
The documentation about scopes is defined here : http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html In maven 1, even if we don't use the scope for dependencies, you can define them with dependency groupId???/groupId artifactId/artifactId version/version properties scopetest/scope /properties /dependency It will be used for the documentation http://maven.apache.org/maven-1.x/dependencies.html and to convert the m1 pom to the m2 pom in the repository http://mavenbook.xwiki.com/xwiki/bin/view/Main/BeMaven2Friendly cheers Arnaud On 3/23/06, Emmanuel Bourg [EMAIL PROTECTED] wrote: Carlos Sanchez wrote: no, scope is different than optional properties optionaltrue/optional /properties What is the definition of an optional dependency ? It depends on the use of the library. If I use a plist configuration most of the time I would not want the commons-codec dependency to be excluded for example. There are several dependency sets depending on the features you are interested in as described here: http://jakarta.apache.org/commons/configuration/dependencies.html It's not obvious to decide what is optional imho. Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL][all] Break dependency on commons-build
I hope that a mavenite may be able to tell us if this helps us use maven 1.1 as I understood that the relative paths were a headache. yes, it helps a lot. I succesfully built the site with maven 1.1 (I just skipped the tests because I have the same errors in IO as reported in the release thread). We have problems with entities (in pom) because we removed xerces and with entities with relative path (in xdoc) because of a bug in dom4j. Arnaud
Re: [pool] Dependency on Xerces
What you can do in maven 1 it's to add a comment and a scope to these dependencies to explain that they are used only for the buildtime and not for the runtime. The documentation isn't yet updated. You can find it here : http://people.apache.org/~aheritier/maven-stage-site/maven-1.x/plugins/xdoc/properties.html#Pom_Settings In the xdoc plugin 1.9.2 I think that at least the comment property is displayed. You'll perhaps need to wait the version 1.10 to display the scope. Arnaud On 3/5/06, Henri Yandell [EMAIL PROTECTED] wrote: I know M2 has stuff for this (different types of dependency). I think for M1 you'd have to either use the maven.xml to tricky the plugin that builds this page, or just write the page by hand and have the navigation point to that hardcoded one. However I don't think we could do that in our current site-nav structure though, don't think M1 lets you modify the navigation links inside the project reports/info sections. So a rather useless reply I guess :) Hopefully it'll lure someone else into giving a constructive answer. Hen On 3/4/06, Stephen Colebourne [EMAIL PROTECTED] wrote: I was confused for a while because the [pool] website says it is dependent on xerces and xml-apis. Now I have downloaded the source, I can see the comment about this being for maven only. Is there any way that these can be removed? The junit one can be removed (even though the mavenites tell you not to). The way the page is generated indicates that [pool] has dependencies, when in fact it doesn't. Stephen - 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: Problems...
SNIP/ Honestly, Lukas, Arnaud and Stephane are doing a great job maintaining and pushing forward on Maven 1.1, so much so that I'm comfortable saying that I'll never work on it again :) I assume they are aware of the issues you are having. Particularly for the entities, I believe the solution is going to be to put Xerces back in the distro as it appears to just be JDK 1.4 that mishandles the entities. Yes, we are aware about these problems. We'll ensure that maven 1.1 will allow the commons-dev team to build their projects. For the entities problem, we'll certainly put back xerces in the core. I have also the idea to enhance the xdoc plugin to allow the user to apply a custom template to the navigation file. I'll do it for the plugins sites in maven to share our commons links. Cheers, Arnaud.
Re: [all] building the site?
Hi Phil, Yes, I'll try to find a solution to use maven 1.1 to build the commons. I'll certainly need to readd xerces to the core :-( to allow you to use XML entities. cheers arnaud On 2/28/06, Phil Steitz [EMAIL PROTECTED] wrote: Both of these requirements - maven 1.0.2 and xdoc 1.9.2 - are included in the getting and installing maven section here http://jakarta.apache.org/commons/building.html Thanks in advance, Arnaud for any help removing the 1.0.2 restriction. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] building the site?
I hink that you need : maven 1.0.2 + xdoc 1.9.2 Arnaud On 2/28/06, Dion Gillard [EMAIL PROTECTED] wrote: Arnaud, if it's a custom xdoc plugin on top of 1.0.2 - which version should I use? On 2/28/06, Arnaud HERITIER [EMAIL PROTECTED] wrote: Dion, I think that you need to upgrade the xdoc plugin. The one bundled in maven 1.0.2 is too old. I'm trying to have maven 1.1 fully compatible with commons site Arnaud On 2/28/06, Dion Gillard [EMAIL PROTECTED] wrote: Maven 1.0.2 fails for a different reason: xdoc:jelly-transform: [echo] Generating C:/source/jakarta/jakarta-commons/jexl/target/docs/changelog- report.html from C:\source\jakarta\ja karta-commons\jexl\target\generated-xdocs\changelog-report.xml Could not find the class: org.apache.commons.jelly.tags.fmt.FmtTagLibrary java.lang.ClassNotFoundException: org.apache.commons.jelly.tags.fmt.FmtTagLibrary at java.net.URLClassLoader$1.run(URLClassLoader.java:199) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:187) Which seems that commons-site.jsl requires the jelly fmt taglib which isn't installed in maven102's lib directory by default. On 2/28/06, Phil Steitz [EMAIL PROTECTED] wrote: Brett or someone more knowledgeable can explain in detail why, but you need to either use maven 1.0.2 or get a more tolerant parser to be loaded. Phil On 2/27/06, Dion Gillard [EMAIL PROTECTED] wrote: Ok, that's what I had, but I still get the following error: BUILD FAILED File.. C:\Documents and Settings\Dion Gillard\.maven\cache\maven-xdoc-plugin-1.9.2\plugin.jelly Element... x:parse Line.. 471 Column -1 Error on line 18 of document : Relative URI ../../commons-build/menus/menus.dtd; can not be resolved without a base U RI. Nested exception: Relative URI ../../commons-build/menus/menus.dtd; can not be resolved without a base URI. Total time : 2 minutes 18 seconds Finished at : Tuesday, 28 February 2006 9:22:43 Any ideas? On 2/27/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Dion Gillard wrote: I've tried to build the site for JEXL, but obviously have the commons-build directory checked out in the wrong location. Is it documented anywhere what the directory structure must be? You can find it here: http://jakarta.apache.org/commons/building.html#Checking%20out%20the%20commons%20sources -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.multitask.com.au/people/dion/ Chuck Norris sleeps with a night light. Not because Chuck Norris is afraid of the dark, but because the dark is afraid of Chuck Norris - 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] -- http://www.multitask.com.au/people/dion/ Chuck Norris sleeps with a night light. Not because Chuck Norris is afraid of the dark, but because the dark is afraid of Chuck Norris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.multitask.com.au/people/dion/ Chuck Norris sleeps with a night light. Not because Chuck Norris is afraid of the dark, but because the dark is afraid of Chuck Norris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] Build fails under Maven 1.1-beta2
Hi Eric, I'll take a look at your problems. Can you send us your errors ? Arnaud On 12/9/05, Eric Pugh [EMAIL PROTECTED] wrote: Hi all, Under maven 1-1.-beta2 there seems to be an issue with the maven- tasks-plugin. I upgraded to 1.2.0 from 1.1.0 to see if that resolved it, but no joy. I actually think the issue is in the project.xml of the tasks plugin. At any rate, if I comment it out, everything is fine. Also, since we are at RC stage, can I bump the versions of the maven- tasks-plugin and maven-findbugs-plugin (should be 1.0!) Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [commons-logging] Remove commons-logging-1.1-dev.jar fromapache repository
This jar was re-added some days ago because some important projects like xdoclet use it in their releases !! Arnaud -Message d'origine- De : robert burrell donkin [mailto:[EMAIL PROTECTED] Envoyé : dimanche 20 novembre 2005 17:54 À : Jakarta Commons Developers List Objet : Re: [commons-logging] Remove commons-logging-1.1-dev.jar fromapache repository On Thu, 2005-11-17 at 16:55 -0800, Carlos Sanchez wrote: Hi, Please remove commons-logging-1.1-dev.jar from http://www.apache.org/dist/java-repository/commons-logging/jars/ ack'd looks like mark diggory put it in there when the repository was starting out - robert - 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: [commons-logging] Remove commons-logging-1.1-dev.jar fromapache repository
Thx For the precision Brett Cheers, Arnaud -Message d'origine- De : Brett Porter [mailto:[EMAIL PROTECTED] Envoyé : lundi 21 novembre 2005 02:02 À : Jakarta Commons Developers List Objet : Re: [commons-logging] Remove commons-logging-1.1-dev.jar fromapache repository Arnaud HERITIER wrote: This jar was re-added some days ago because some important projects like xdoclet use it in their releases !! ... re-added to ibiblio for the sake of backwards compatibility for those other projects, but not Apache as it should be only official releases there. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [all][POLL] what files to fixcrlf for windows distributions
Hi, I opened these issue to add a property to allow us to select the filter : http://jira.codehaus.org/browse/MPDIST-28 Isn't it useful to ensure that the LF line ending is used in Unix Archives ? Arnaud -Message d'origine- De : Dion Gillard [mailto:[EMAIL PROTECTED] Envoyé : mardi 15 novembre 2005 10:02 À : Jakarta Commons Developers List Objet : Re: [all][POLL] what files to fixcrlf for windows distributions As someone who uses Windows on a daily basis, I've never had a pproblem with the LF line endings and hence would only filter *.txt in a binary distribution. On 11/15/05, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! It turns out that it is required to fix the crlf (EOL) thing when building distributions for windows distributions. A windows distribution is a distribution packed as zip file. Maven will add support to define a filter to setup the extension of the files to convert. Anyway I think we should find a standard how to setup this filter. The extension in question are: [ ] .txt [ ] .java [ ] .properties [ ] .xml [ ] .css .java, .properties, .xml, .css might be problematic as we might get diffs with the wrong line ending then - on the other hand for an developer its not needed as every IDE can handle LF only line endings and our source code format should define this (the LF ending) as required. So only .txt might be save as this is generally the release notes files and getting patches for it is very unlikely ;-) What do you think? My personal vote goes to .txt only. Thanks! Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.multitask.com.au/people/dion/ You are going to let the fear of poverty govern your life and your reward will be that you will eat, but you will not live. - George Bernard Shaw - 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] dist plugin for zip-crlf conversation (was: [vfs][VOTE] release version 1.0)
Hi Mario, For the assert:assertPluginAvailable tag you need the last plugin-plugin. Sorry, we'll try to simplify this ASAP. For maven 1.1, did you try the bootstrap ? What is the error ? Can you send it to me please. I will publish in some minutes a new snapshot for the dist plugin. You'll be able to retreive it with : maven plugin:download -Dmaven.repo.remote=http://cvs.apache.org/repository/ -DgroupId=maven -DartifactId=maven-dist-plugin -Dversion=1.7-SNAPSHOT I'm agree for *.java in sources. Can you open an issue please ? Arnaud -Message d'origine- De : Mario Ivankovits [mailto:[EMAIL PROTECTED] Envoyé : lundi 14 novembre 2005 09:37 À : Jakarta Commons Developers List Objet : Re: [maven] dist plugin for zip-crlf conversation (was: [vfs][VOTE] release version 1.0) Phil Steitz wrote: Has now been fixed in svn. So if you checkout the latest maven 1 dist plugin sources from http://svn.apache.org/repos/asf/maven/maven-1/plugins/trunk/dist/ and then do maven plugin:install from the dist plugin directory, maven dist will put windows style line endings in the zips. Thanks! But it was a challenge to install. I had to remove the assert:assertPluginAvailable tag from plugin.jelly and to build plugin-xdoc too, to make it work with maven 1.0.2. BTW: I tried to build maven 1.1 but its tests failed, so I gave up. Now dist fixes *.txt files, but I thought it should fix *.java too, shouldnt it? --- Mario - 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] dist plugin for zip-crlf conversation (was: [vfs][VOTE] release version 1.0)
Yes, it could be a good idea to have a property to define the filter for files
to change EOL.
Is there someone who can open an issue ? I'll do it in the next days.
Arnaud
-Message d'origine-
De : Phil Steitz [mailto:[EMAIL PROTECTED]
Envoyé : mardi 15 novembre 2005 06:32
À : Jakarta Commons Developers List
Objet : Re: [maven] dist plugin for zip-crlf conversation
(was: [vfs][VOTE] release version 1.0)
On 11/14/05, Stephen Colebourne [EMAIL PROTECTED] wrote:
Phil Steitz wrote:
That will screw up diffs, won't it? Probably best to leave the
sources along and just apply to .txt files, as the
current version
does.
Not sure about that. When I use subversion to get files they end up
with Windows EOL. I think thats what we are trying to replicate.
We should be consistent in any case. Right now the Ant build
for [collections] does this:
fixcrlf srcdir=${build.dist.src.work} eol=crlf
includes=*.txt,*.properties /
and [io] does this
fixcrlf srcdir=${dist.src} eol=crlf
includes=*.txt,*.xml,*.css,*.properties /
Neither appear to mess with the java sources. Do many people
open the java files in windows editors not capable of
handling lf line endings?
Could be the right solution for the maven dist plugin is to
expose a property that holds the filter.
Phil
-
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: [jelly] attempting big speed improvement
We'll be happy to test it in maven 1.x Arnaud -Message d'origine- De : Dion Gillard [mailto:[EMAIL PROTECTED] Envoyé : dimanche 6 novembre 2005 20:58 À : Jakarta Commons Developers List Objet : Re: [jelly] attempting big speed improvement Sounds good. Commit away and we can all test. On 11/7/05, Hans Gilde [EMAIL PROTECTED] wrote: A while ago, I noticed a potential for a huge speed improvement with Jelly. Basically, it uses this DynaBean stuff which sounds good, but was never taken anywhere within Jelly. Because of this, every tag goes through 3 stages of having its attributes set from XML and I plan to knock that down to 1. I branched Jelly, will send an update when I have something. All my changes are to the very core of Jelly, where I doubt anyone else goes. So, I don't expect the changes to affect any class or interface that is actually used by tag developers. Hans -- http://www.multitask.com.au/people/dion/ You are going to let the fear of poverty govern your life and your reward will be that you will eat, but you will not live. - George Bernard Shaw - 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: [math] math 1.1 RCs and FCS
You can publish snapshot on this repository which isn't synchronized with
ibiblio.
It's where we put all our snapshots (comes from project.properties.sample in
commons-build)
# Repository to deploy snapshots
maven.repo.apache.snapshots=scp://cvs.apache.org
maven.repo.apache.snapshots.directory=/www/cvs.apache.org/repository
maven.repo.apache.snapshots.username=${maven.repo.apache.releases.username}
maven.repo.apache.snapshots.privatekey=${maven.repo.apache.releases.privatekey}
maven.repo.apache.snapshots.passphrase=${maven.repo.apache.releases.passphrase}
maven.repo.apache.snapshots.group=${maven.repo.apache.releases.group}
Arnaud
-Message d'origine-
De : news [mailto:[EMAIL PROTECTED] De la part de Mauro Talevi
Envoyé : samedi 15 octobre 2005 14:10
À : commons-dev@jakarta.apache.org
Objet : Re: [math] math 1.1 RCs and FCS
Phil Steitz wrote:
I understand, unfortunately this is against our release policy (at
least publishing to ibiblio). I will try to get the actual release
out ASAP.
Just to understand - this release policy seems specific to
the commons math project, since other commons projects seem
to deploy RCs and snapshots. If so - is there any specific
reason for it?
If not on ibiblio - perhaps another URL on ASF where to
deploy the jars?
They would be not be considered public releases - just like
the zip and tar.gz distributions.
IMO it would make it a lot easier to test the RCs in real
production projects and would benefit the commons math project.
Cheers
-
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: [math] math 1.1 RCs and FCS
I think that http://cvs.apache.org/dist/ is used to distribute packages. It doesn't follow the maven repository layout. The repository to store snapshots for maven is http://cvs.apache.org/repository/ Arnaud -Message d'origine- De : Rahul Akolkar [mailto:[EMAIL PROTECTED] Envoyé : samedi 15 octobre 2005 17:53 À : Jakarta Commons Developers List Objet : Re: [math] math 1.1 RCs and FCS On 10/15/05, Arnaud HERITIER [EMAIL PROTECTED] wrote: You can publish snapshot on this repository which isn't synchronized with ibiblio. It's where we put all our snapshots (comes from project.properties.sample in commons-build) # Repository to deploy snapshots maven.repo.apache.snapshots=scp://cvs.apache.org maven.repo.apache.snapshots.directory=/www/cvs.apache.org/repository snip/ So, whats /www/cvs.apache.org/dist/jakarta for? I see snapshots there, and I remember it being referred to as the place to put snapshots. Thanks! -Rahul - 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]
[beautils] incompatibility between 1.6.1 and 1.7.0 ?
Hi Guys, I would like to know if there's a known issue about the incompability between beanutils 1.6.1 and beanutils 1.7.0 ? I searched in bugzilla but I didn't find something like that. I'm trying to upgrade beanutils in maven and I receive this error : [exec] Method invocation failed. [exec] java.lang.IllegalArgumentException: [EMAIL PROTECTED] [exec] at sun.reflect.GeneratedMethodAccessor57.invoke(Unknown Source) [exec] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [exec] at java.lang.reflect.Method.invoke(Method.java:324) [exec] at org.apache.commons.beanutils.PropertyUtilsBean.invokeMethod(PropertyUtilsBean.java:1773) [exec] at org.apache.commons.beanutils.PropertyUtilsBean.setSimpleProperty(PropertyUtilsBean.java:1759) [exec] at org.apache.commons.beanutils.PropertyUtilsBean.setNestedProperty(PropertyUtilsBean.java:1648) [exec] at org.apache.commons.beanutils.PropertyUtilsBean.setProperty(PropertyUtilsBean.java:1677) [exec] at org.apache.commons.beanutils.BeanUtilsBean.setProperty(BeanUtilsBean.java:1022) [exec] at org.apache.commons.beanutils.BeanUtils.setProperty(BeanUtils.java:313) [exec] at org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:263) [exec] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:247) [exec] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [exec] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) [exec] at org.apache.commons.jelly.TagSupport.getBodyText(TagSupport.java:234) [exec] at org.apache.commons.jelly.TagSupport.getBodyText(TagSupport.java:222) [exec] at org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:237) [exec] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:247) [exec] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [exec] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) [exec] at org.apache.commons.jelly.TagSupport.getBodyText(TagSupport.java:234) [exec] at org.apache.commons.jelly.TagSupport.getBodyText(TagSupport.java:222) [exec] at org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:160) [exec] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:247) [exec] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [exec] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) [exec] at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:42) [exec] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:247) [exec] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [exec] at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:78) [exec] at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:109) [exec] at org.apache.maven.werkz.Goal.fire(Goal.java:656) [exec] at org.apache.maven.werkz.Goal.attain(Goal.java:592) [exec] at org.apache.maven.werkz.Goal.attainPrecursors(Goal.java:505) [exec] at org.apache.maven.werkz.Goal.attain(Goal.java:590) [exec] at org.apache.maven.werkz.Goal.attainPrecursors(Goal.java:505) [exec] at org.apache.maven.werkz.Goal.attain(Goal.java:590) [exec] at org.apache.maven.werkz.WerkzProject.attainGoal(WerkzProject.java:210) [exec] at org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:114) [exec] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:247) [exec] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [exec] at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:78) [exec] at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:109) [exec] at org.apache.maven.werkz.Goal.fire(Goal.java:656) [exec] at org.apache.maven.werkz.Goal.attain(Goal.java:592) [exec] at org.apache.maven.werkz.Goal.attainPrecursors(Goal.java:505) [exec] at org.apache.maven.werkz.Goal.attain(Goal.java:590) [exec] at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:693) [exec] at org.apache.maven.MavenSession.attainGoals(MavenSession.java:263) [exec] at org.apache.maven.jelly.tags.maven.ReactorTag.doTag(ReactorTag.java:368) [exec] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:247) [exec] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [exec] at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:78) [exec] at
RE: [beautils] incompatibility between 1.6.1 and 1.7.0 ?
Hi Dion, Not yet and I think that's the problem ;-) You confirm me in my idea ! I'll try to test it. But if beanutils kept the same API (with only some add-ons), I couldn't have a ClassCastException ? Arnaud -Message d'origine- De : Dion Gillard [mailto:[EMAIL PROTECTED] Envoyé : jeudi 13 octobre 2005 00:35 À : Jakarta Commons Developers List Objet : Re: [beautils] incompatibility between 1.6.1 and 1.7.0 ? Have you tested Jelly with BeanUtils 1.7? AFAIK, we've only released against 1.6.1 (See http://svn.apache.org/repos/asf/jakarta/commons/proper/jelly/t runk/parent-project.xml ). On 10/13/05, Arnaud HERITIER [EMAIL PROTECTED] wrote: Hi Guys, I would like to know if there's a known issue about the incompability between beanutils 1.6.1 and beanutils 1.7.0 ? I searched in bugzilla but I didn't find something like that. I'm trying to upgrade beanutils in maven and I receive this error : [exec] Method invocation failed. [exec] java.lang.IllegalArgumentException: [EMAIL PROTECTED] [exec] at sun.reflect.GeneratedMethodAccessor57.invoke(Unknown Source) [exec] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMeth odAccessorImpl.java:25) [exec] at java.lang.reflect.Method.invoke(Method.java:324) [exec] at org.apache.commons.beanutils.PropertyUtilsBean.invokeMethod(Pr opertyUtilsBean.java:1773) [exec] at org.apache.commons.beanutils.PropertyUtilsBean.setSimpleProper ty(PropertyUtilsBean.java:1759) [exec] at org.apache.commons.beanutils.PropertyUtilsBean.setNestedProper ty(PropertyUtilsBean.java:1648) [exec] at org.apache.commons.beanutils.PropertyUtilsBean.setProperty(Pro pertyUtilsBean.java:1677) [exec] at org.apache.commons.beanutils.BeanUtilsBean.setProperty(BeanUti lsBean.java:1022) [exec] at org.apache.commons.beanutils.BeanUtils.setProperty(BeanUtils.java:313) [exec] at org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:263) [exec] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:247) [exec] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [exec] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) [exec] at org.apache.commons.jelly.TagSupport.getBodyText(TagSupport.java:234) [exec] at org.apache.commons.jelly.TagSupport.getBodyText(TagSupport.java:222) [exec] at org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:237) [exec] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:247) [exec] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [exec] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) [exec] at org.apache.commons.jelly.TagSupport.getBodyText(TagSupport.java:234) [exec] at org.apache.commons.jelly.TagSupport.getBodyText(TagSupport.java:222) [exec] at org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:160) [exec] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:247) [exec] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [exec] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) [exec] at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:42) [exec] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:247) [exec] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [exec] at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(Mave nGoalTag.java:78) [exec] at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction .performAction(MavenGoalTag.java:109) [exec] at org.apache.maven.werkz.Goal.fire(Goal.java:656) [exec] at org.apache.maven.werkz.Goal.attain(Goal.java:592) [exec] at org.apache.maven.werkz.Goal.attainPrecursors(Goal.java:505) [exec] at org.apache.maven.werkz.Goal.attain(Goal.java:590) [exec] at org.apache.maven.werkz.Goal.attainPrecursors(Goal.java:505) [exec] at org.apache.maven.werkz.Goal.attain(Goal.java:590) [exec] at org.apache.maven.werkz.WerkzProject.attainGoal(WerkzProject.java:210) [exec] at org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(Mav enAttainGoalTag.java:114) [exec] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:247) [exec] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [exec] at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(Mave nGoalTag.java:78) [exec] at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction .performAction(MavenGoalTag.java:109) [exec
RE: [collections] Bug Fix Help wanted! (so we can release v3.2)
There is no evidence that we introduced this since 3.1. I believe it has been there since class creation in 3.0 (or alternatively that there is in fact no problem at all) I don't know about releasing such a version with debugging and a known regression. perhaps labelled 3.2-beta with the extra debugging info to try and track it down? I've uploaded a jar to bugzilla with debugging. Hi Stephen It could be easier for maven users to test it if you add a SNAPSHOT in the repository : /www/cvs.apache.org/repository Arnaud - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [logging] log4j-1.2.12 at ibiblio?
It was done some days ago http://www.ibiblio.org/maven/log4j/jars/ Arnaud -Message d'origine- De : Joerg Hohwiller [mailto:[EMAIL PROTECTED] Envoyé : jeudi 29 septembre 2005 23:12 À : log4j-dev@logging.apache.org Cc : Jakarta Commons Developers List Objet : [logging] log4j-1.2.12 at ibiblio? -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there log4j-community, Log4j 1.2.12 was released and invented the loglevel Trace. We from commons-logging have been asked to use this level if available for tracing if log4j is the underlying native logger implementation. This has been done now and will be in the upcomming 1.0.5 release of jcl. Could someone of you guyz be so neat and updload the log4j 1.2.12 jar at ibiblio so we can update our maven dependencies and the current state will build properly? Thank you! Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDPFiPmPuec2Dcv/8RAuSbAJ988+63WxHhZ/rHEBpbSdPfB6igvQCfYTr9 YpAwGTccIgwlibnPbD2z5uU= =V92f -END PGP SIGNATURE- - 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: [commons-build] Site build problem
This turned out to be a bug in the site.jsl. A patch has been applied to svn and this will be fixed in version 1.10 of the xdoc plugin. Here is an example site generated using the patched plugin and maven.xdoc.theme=classic maven.ui.banner.background=#fff http://people.apache.org/~psteitz/classic.html The nav entry Commons Resources (Unofficial) is too wide to fit (and maven.ui.navcol.width seems to no longer do anything); but otherwise this looks OK to me. Others may have different opinions; but if this looks good enough I would suggest that we tweak the menus, etc. to work with this setup and migrate away from using custom style sheets. We could get things working right away by just dropping the type='header' from the About Us menu. The big advantage of going this route is that we would then no longer need to maintain commons-site.jsl, nor to copy the stylesheets out to the distributions. Phil Can you open an issue for the problem with maven.ui.navcol.width ? We'll fix it (if possible) for the release 1.10 I think you removed the icons used to show External Links and New Windows. You should remove the legend. maven.xdoc.legend=false cheers, Arnaud
RE: [commons-build] Site build problem
I opened a new bug for this incompatibility issue. http://jira.codehaus.org/browse/MPXDOC-167 Arnaud -Message d'origine- De : Niall Pemberton [mailto:[EMAIL PROTECTED] Envoyé : lundi 12 septembre 2005 06:14 À : Jakarta Commons Developers List Objet : Re: [commons-build] Site build problem - Original Message - From: Brett Porter [EMAIL PROTECTED] Sent: Monday, September 12, 2005 2:36 AM I think this option I raised earlier got missed, so I'll repeat here: The one option I'd consider is whether it is worth ditching commons-site.jsl altogether. I have no idea what it adds: setting maven.xdoc.theme=classic instead looks the same to me (except for the addition of the the external link icons which can be removed through CSS). If you'd like me to commit that for commons-math I can. Does anyone know what it was meant to do, other than insulate against changes in the Maven generated site? One thing it does is add the standard commons About Us menu before the project menu. I know that doesn't solve the fundamental problem in the plugin, but might be the best solution for commons. IMO we would still need have a dependency on a specific xdoc plugin version - otherwise what different components' sites look like could vary depending on what version plugin happened to be installed. Niall - 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: [i18n] Remaining issues
My 2 cents, * Synchronize Maven (project.xml) and Ant (build.xml). Proposed fix: Add jcoverage test coverage to build.xml. (I have EMMA test coverage with Ant locally). This might imply adding jcoverage jars to a lib dir. To simplify your devs, - You can generate a minimal build.xml from maven with the ant plugin : http://maven.apache.org/reference/plugins/ant/ - You can use the jcoverage report in maven : http://maven.apache.org/reference/plugins/jcoverage/ Arnaud - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: maven question
Hi Kyle, The first time you need to add an environment in your eclipse settings to define your maven repository home : maven -Dmaven.eclipse.workspace=/your/path/to/your/eclipse/workspace eclipse:add-maven-repo Then, in any maven project you generate your eclipse configuration : maven eclipse and you import it in eclipse (import an existing project ... in eclipse) Arnaud -Message d'origine- De : Kyle Miller [mailto:[EMAIL PROTECTED] Envoyé : mercredi 13 avril 2005 15:11 À : commons-dev@jakarta.apache.org Objet : maven question I have just started using maven on my first project, but I have been playing with it at home. My question for the commons developers is this, every project here uses maven, and I would assume many of you also use eclipse or some other similar IDE. Has anyone found a good way to add the jars managed by maven to your IDE classpath? In previous projects I would just put all of the jars in the lib directory and check them into CVS. - 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]
Maven plugins was: [httpclient] Jars in the repository
Here is the list of updated core plugins since maven 1.0.2 was released : Maven Ant Plugin1.9 2005-04-09 Maven Dashboard Plugin 1.7 2005-03-05 Maven Clover Plugin 1.8 2005-03-04 Maven Hibernate Plug-in 1.3 2005-02-10 Maven Site Plugin 1.6 2005-01-18 Maven Changelog Plugin 1.7.2 2005-01-08 Maven Gump Plug-in 2.0 2005-01-08 Maven EAR Plugin1.6.1 2004-12-10 Arnaud -Message d'origine- De : Arnaud HERITIER [mailto:[EMAIL PROTECTED] Envoyé : dimanche 10 avril 2005 15:45 À : 'Jakarta Commons Developers List' Objet : RE: [httpclient] Jars in the repository Hi Dion, I just published the maven-plugins site. You'll find the list of plugins released after maven 1.0.2 (7th December) in this page in some hours (depending of the sync between www.apache.org and people.apache.org): http://maven.apache.org/reference/plugins/multichanges-report.html We didn't yet publish a new maven release with this new plugins set. I think it'll be done with maven 1.1 Arnaud -Message d'origine- De : Dion Gillard [mailto:[EMAIL PROTECTED] Envoyé : dimanche 10 avril 2005 12:27 À : Jakarta Commons Developers List Objet : Re: [httpclient] Jars in the repository Arnaud, is there an up to date list of released plugins for maven 1.0.2? Maybe a bundle with the latest of each released since the 1.0.2 release? On Apr 10, 2005 7:58 PM, Arnaud HERITIER [EMAIL PROTECTED] wrote: Hi guys, [SNIP] I'll ask the maintainer of the plugin, if it is possible to get an official release of it. It's done. You can download it (maven plugin:download -DartifactId=maven-ant-plugin -DgroupId=maven -Dversion=1.9) and use it (maven ant). From now, you can use external properties to configure the generated ant script (to override dependencies for example) : http://maven.apache.org/reference/plugins/ant/ant-settings.html If you already have an handwritten ant script, be careful to use the property 'maven.ant.generatebuild.file' to change the name of the generated one (http://maven.apache.org/reference/plugins/ant/properties.html) We hope that this new release will help you. Do not hesitate to open issues if needed : http://jira.codehaus.org/browse/MPANT Cheers, Arnaud - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.multitask.com.au/people/dion/ - 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]
[ANN] Maven Ant Plugin 1.9 release
The maven team is pleased to announce the Maven Ant Plugin 1.9 release!
http://maven.apache.org/reference/plugins/ant/
Generates ant build files from a maven project, so that plain ant users can
build your project
Changes in this version include:
New Features:
o Ant script looks for dependencies in several remote repositories. Issue:
MPANT-24.
o Add License file to jar META-INF. Issue: MPANT-23. Thanks to Phil Steitz.
o Allow URL substitutions in generated build.xml files. Issue: MPANT-20.
Thanks to Dennis Lundberg,Craig McClanahan.
o Obey jar override and not attempt to download relative jars. Issue:
MPANT-7.
o Ant user can set proxy settings.
o New property maven.ant.compatibility if you want a script compatible with
ant 1.5 (actually for proxy settings).
Changes:
o get-deps target store downloads to the default local maven repository (
${user.home}/.maven/repository). Issue: MPANT-21.
To automatically install the plugin, type the following on a single line:
maven plugin:download
-DgroupId=maven
-DartifactId=maven-ant-plugin
-Dversion=1.9
For a manual installation, you can download the plugin here:
http://www.apache.org/dyn/closer.cgi/java-repository/maven/plugins/maven-ant-plugin-1.9.jar
Have fun!
-The maven team
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [httpclient] Jars in the repository
Hi guys, [SNIP] I'll ask the maintainer of the plugin, if it is possible to get an official release of it. It's done. You can download it (maven plugin:download -DartifactId=maven-ant-plugin -DgroupId=maven -Dversion=1.9) and use it (maven ant). From now, you can use external properties to configure the generated ant script (to override dependencies for example) : http://maven.apache.org/reference/plugins/ant/ant-settings.html If you already have an handwritten ant script, be careful to use the property 'maven.ant.generatebuild.file' to change the name of the generated one (http://maven.apache.org/reference/plugins/ant/properties.html) We hope that this new release will help you. Do not hesitate to open issues if needed : http://jira.codehaus.org/browse/MPANT Cheers, Arnaud - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [httpclient] Jars in the repository
Hi Dion, I just published the maven-plugins site. You'll find the list of plugins released after maven 1.0.2 (7th December) in this page in some hours (depending of the sync between www.apache.org and people.apache.org): http://maven.apache.org/reference/plugins/multichanges-report.html We didn't yet publish a new maven release with this new plugins set. I think it'll be done with maven 1.1 Arnaud -Message d'origine- De : Dion Gillard [mailto:[EMAIL PROTECTED] Envoyé : dimanche 10 avril 2005 12:27 À : Jakarta Commons Developers List Objet : Re: [httpclient] Jars in the repository Arnaud, is there an up to date list of released plugins for maven 1.0.2? Maybe a bundle with the latest of each released since the 1.0.2 release? On Apr 10, 2005 7:58 PM, Arnaud HERITIER [EMAIL PROTECTED] wrote: Hi guys, [SNIP] I'll ask the maintainer of the plugin, if it is possible to get an official release of it. It's done. You can download it (maven plugin:download -DartifactId=maven-ant-plugin -DgroupId=maven -Dversion=1.9) and use it (maven ant). From now, you can use external properties to configure the generated ant script (to override dependencies for example) : http://maven.apache.org/reference/plugins/ant/ant-settings.html If you already have an handwritten ant script, be careful to use the property 'maven.ant.generatebuild.file' to change the name of the generated one (http://maven.apache.org/reference/plugins/ant/properties.html) We hope that this new release will help you. Do not hesitate to open issues if needed : http://jira.codehaus.org/browse/MPANT Cheers, Arnaud - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.multitask.com.au/people/dion/ - 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: [VOTE] Release commons email 1.0
With 1.9 the generated ant file allows the user to set itself the
dependency with a property.
I published the doc here :
http://www.apache.org/~brett/maven-stage-site/reference/plugins/ant/
You can try it :
maven plugin:download
-Dmaven.repo.remote=http://cvs.apache.org/repository
-DgroupId=maven
-DartifactId=maven-ant-plugin
-Dversion=SNAPSHOT
If you find a problem we can resolve them before the 1.9 release.
Arnaud
On Fri, 4 Mar 2005 08:59:50 -0800, Eric Pugh [EMAIL PROTECTED] wrote:
I am using 1.8.1. However, I just found out that the darn jars aren't
supposed to be on ibiblio. I checked on the maven mailing list and
found out it was a problem. Silly me for bringing it up.. So now I
need to rollback to the older version.
Does the 1.9-SNAPSHOT help this situation of non redistributable jars?
Eric
-Original Message-
From: Arnaud HERITIER [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 03, 2005 9:42 AM
To: 'Jakarta Commons Developers List'
Subject: RE: [VOTE] Release commons email 1.0
Do you use the ant plugin 1.8.1 for maven or the 1.9-SNAPSHOT ?
Arnaud
-Message d'origine-
De : Eric Pugh [mailto:[EMAIL PROTECTED]
Envoyé : jeudi 3 mars 2005 16:48
À : 'Jakarta Commons Developers List'
Objet : RE: [VOTE] Release commons email 1.0
Okay..
I'll take care of those changes.
The build.xml could definitly be out of date.. It has been patched a
couple times by hand, and then we have had those patches get wiped out
by the Maven build. Recently some patches were added to the
Maven Ant
plugin, it may be that the hand tweaking is no longer
required. Did
you get this error: no protocol: ${javamail-1.3.2.url}? I
am going to regenerate the Maven one and commit it.
I have tweaked the docs, I'll try and tackle the other little
changes today.
Eric Pugh
-Original Message-
From: Phil Steitz [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 02, 2005 3:49 PM
To: Jakarta Commons Developers List
Subject: Re: [VOTE] Release commons email 1.0
+1 modulo the following nits:
* Binary distro includes NOTICE.txt in the jar (top level, should
probably be with LICENSE.txt in META-INF) but not in the top level
directory of the distribution.
* Source distro does not include NOTICE.txt
* Ant build.xml in source distro fails with
MalformedURLException in get
deps. When I regenerated the build.xml using maven ant, the
regenerated
build.xml worked. Could be build.xml is out of date?
* Make sure to update the repo link on the web site to point to svn.
Phil
robert burrell donkin wrote:
On Tue, 2005-03-01 at 06:58, Eric Pugh wrote:
[X] +1 Lets release commons-email, it's been too long!
[ ] 0 Commons-what? Not ready for release
[ ] -1 Don't release. I can't get dumbster (replace with your
reason) to work.
BTW i've checked the sums and signatures
- robert
-
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]
-
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: [VOTE] Release commons email 1.0
Do you use the ant plugin 1.8.1 for maven or the 1.9-SNAPSHOT ?
Arnaud
-Message d'origine-
De : Eric Pugh [mailto:[EMAIL PROTECTED]
Envoyé : jeudi 3 mars 2005 16:48
À : 'Jakarta Commons Developers List'
Objet : RE: [VOTE] Release commons email 1.0
Okay..
I'll take care of those changes.
The build.xml could definitly be out of date.. It has been patched a
couple times by hand, and then we have had those patches get wiped out
by the Maven build. Recently some patches were added to the
Maven Ant
plugin, it may be that the hand tweaking is no longer
required. Did
you get this error: no protocol: ${javamail-1.3.2.url}? I
am going to regenerate the Maven one and commit it.
I have tweaked the docs, I'll try and tackle the other little
changes today.
Eric Pugh
-Original Message-
From: Phil Steitz [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 02, 2005 3:49 PM
To: Jakarta Commons Developers List
Subject: Re: [VOTE] Release commons email 1.0
+1 modulo the following nits:
* Binary distro includes NOTICE.txt in the jar (top level, should
probably be with LICENSE.txt in META-INF) but not in the top level
directory of the distribution.
* Source distro does not include NOTICE.txt
* Ant build.xml in source distro fails with
MalformedURLException in get
deps. When I regenerated the build.xml using maven ant, the
regenerated
build.xml worked. Could be build.xml is out of date?
* Make sure to update the repo link on the web site to point to svn.
Phil
robert burrell donkin wrote:
On Tue, 2005-03-01 at 06:58, Eric Pugh wrote:
[X] +1 Lets release commons-email, it's been too long!
[ ] 0 Commons-what? Not ready for release
[ ] -1 Don't release. I can't get dumbster (replace with your
reason) to work.
BTW i've checked the sums and signatures
- robert
-
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: cvs commit: jakarta-commons/jexl/xdocs/reference syntax.xml
Hi Dion, Just one question: How is it possible to support at the same time variables in ant-style and the syntax to access properties (http://jakarta.apache.org/commons/jexl/reference/examples.html#Example%20Expressions)? How do I make the difference between a variable named x.y and a variable x with a getter getY() ?? I had a problem with this in Maven plugins. I had a bug because I used a dotted variable name. Is there a difference between variables names and properties names ? Arnaud On 5 Sep 2004 09:00:56 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: dion2004/09/05 02:00:56 Modified:jexl/xdocs/reference syntax.xml Log: Docs on ant-style properties Revision ChangesPath 1.12 +9 -0 jakarta-commons/jexl/xdocs/reference/syntax.xml Index: syntax.xml === RCS file: /home/cvs/jakarta-commons/jexl/xdocs/reference/syntax.xml,v retrieving revision 1.11 retrieving revision 1.12 diff -u -r1.11 -r1.12 --- syntax.xml23 Aug 2004 00:55:09 - 1.11 +++ syntax.xml5 Sep 2004 09:00:55 - 1.12 @@ -57,6 +57,15 @@ liValid: codevar1/code,code_a99/code,code$1/code/li liInvalid: code9v/code,code!a99/code,code1$/code/li /ul +p + JEXL also supports codeant-style/code variables, e.g. sourcemy.dotted.var/source + is a valid variable name. +/p +p + strongNOTE:/strong JEXL does not support variables with hyphens in them, e.g. + sourcecommons-logging/source is not a valid variable, but instead is treated as a + subtraction of the variable codelogging/code from the variable codecommons/code +/p /td /tr tr - 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: cvs commit: jakarta-commons/jexl/xdocs/reference syntax.xml
Just one question: How is it possible to support at the same time variables in ant-style and the syntax to access properties Properties will get precedence. ok. How do I make the difference between a variable named x.y and a variable x with a getter getY() ?? There is none. The property will win. ok it's logic. I had a problem with this in Maven plugins. I had a bug because I used a dotted variable name. Is there a difference between variables names and properties names ? No The problem you had was with the empty function and dotted variables. This has very recently been fixed in JEXL, and not yet incorporated into Jelly. Once JEXL is released, and Jelly picks up that, your original code will work as you expected. I understand. thanks for the explanation. Arnaud - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [any] NoClassDefFoundError trying to build with Maven 1.0
Hi martin, Can you add the -X option to launch maven and send us (on this list or on the maven users list or on Jira) the log please. Arnaud -Message d'origine- De : Martin Cooper [mailto:[EMAIL PROTECTED] Envoyé : dimanche 25 juillet 2004 17:45 À : Jakarta Commons Developers List Objet : Re: [any] NoClassDefFoundError trying to build with Maven 1.0 On Sun, 25 Jul 2004 12:11:58 +0200, Dennis Lundberg [EMAIL PROTECTED] wrote: Did you remember to erase the .maven folder in your home directory? A Well, what I meant by a clean machine is one that has ever seen Maven before. However, I've tried blowing every trace of Maven off the machine and starting again, and still no deal. ;-( common cause for trouble is having files there from an older version of Maven. I did this on my machine: - Delete %USER_HOME%\.maven - Install Maven 1.0 final - cvs update on + jakarta-commons/commons-build + jakarta-commons/logging - Run maven clean dist in logging It works fine. Hmmph. I just tried exactly that, and no deal for me. BTW, I'm running on Win2K, Sun JDK 1.4.2_04. Looks like you're running on some flavour of Windows too, so it's probably not a Windows thing. I've tried using the installer and the vanilla zip file, and it makes no difference. ;-( -- Martin Cooper -- Dennis Lundberg Martin Cooper wrote: So I installed Maven 1.0 on a clean machine, and now any Commons component I try to build fails with a NoClassDefFoundError, complaining about a missing MethodInvocationException from Velocity. I checked the maven-user archives, and all I can find is a message from jvz saying to add the Velocity jar as a dependency in project.xml. This doesn't sound right, because I can't believe that all of the components I've tried to build so far are missing the exact same change in their project.xml file, and I haven't seen anyone else griping about this problem here, so other people must have it working. Obviously I'm missing something else. Can someone clue me in? TIA. -- Martin Cooper - 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: [any] NoClassDefFoundError trying to build with Maven 1.0
This is strange, This error occurs several times: Error retrieving artifact from [http://www.ibiblio.org/maven/log4j/jars/log4j-1.2.6.jar]: java.net.SocketException: No buffer space available (maximum connections reached?): recv failed Error retrieving artifact from [http://www.ibiblio.org/maven/logkit/jars/logkit-1.0.1.jar]: java.net.SocketException: No buffer space available (maximum connections reached?): recv failed Error retrieving artifact from [http://www.ibiblio.org/maven/junit/jars/junit-3.7.jar]: java.net.SocketException: No buffer space available (maximum connections reached?): recv failed Error retrieving artifact from [http://www.ibiblio.org/maven/avalon-framework/jars/avalon-framework-4.1.3.jar]: java.net.SocketException: No buffer space available (maximum connections reached?): recv failed Error retrieving artifact from [http://www.ibiblio.org/maven/velocity/jars/velocity-1.4-dev.jar]: java.net.SocketException: No buffer space available (maximum connections reached?): recv failed Don't you have a problem with the internet connection on this computer ? Can you access to ibiblio? Don't you have a filesystem full ?? Arnaud -Message d'origine- De : matthew.hawthorne [mailto:[EMAIL PROTECTED] Envoyé : dimanche 25 juillet 2004 19:14 À : Jakarta Commons Developers List Objet : Re: [any] NoClassDefFoundError trying to build with Maven 1.0 This strange error was in the log you provided. I'm not sure if it's occurring due to ibiblio being overloaded, or what. But perhaps it's the cause of your problems? Getting URL: http://www.ibiblio.org/maven/velocity/jars/velocity-1.4-dev.jar Received status code: 200 last-modified = Fri, 30 Jan 2004 00:50:23 GMT (1075423823000) Error retrieving artifact from [http://www.ibiblio.org/maven/velocity/jars/veloc ity-1.4-dev.jar]: java.net.SocketException: No buffer space available (maximum c onnections reached?): recv failed Error details java.net.SocketException: No buffer space available (maximum connections reached ?): recv failed at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:129) at java.io.FilterInputStream.read(FilterInputStream.java:111) at java.io.PushbackInputStream.read(PushbackInputStream.java:161) at java.io.FilterInputStream.read(FilterInputStream.java:111) at org.apache.commons.httpclient.ContentLengthInputStream.read(ContentLe ngthInputStream.java:167) at java.io.FilterInputStream.read(FilterInputStream.java:111) at org.apache.commons.httpclient.AutoCloseInputStream.read(AutoCloseInpu tStream.java:142) at java.io.FilterInputStream.read(FilterInputStream.java:90) at org.apache.commons.httpclient.AutoCloseInputStream.read(AutoCloseInpu tStream.java:161) at org.apache.maven.util.HttpUtils.process(HttpUtils.java:572) at org.apache.maven.util.HttpUtils.retrieveArtifact(HttpUtils.java:538) at org.apache.maven.util.HttpUtils.getFile(HttpUtils.java:381) at org.apache.maven.util.HttpUtils.getFile(HttpUtils.java:287) at org.apache.maven.util.HttpUtils.getFile(HttpUtils.java:181) at org.apache.maven.verifier.DependencyVerifier.getRemoteArtifact(Depend encyVerifier.java:326) at org.apache.maven.verifier.DependencyVerifier.getDependencies(Dependen cyVerifier.java:255) at org.apache.maven.verifier.DependencyVerifier.satisfyDependencies(Depe ndencyVerifier.java:171) at org.apache.maven.verifier.DependencyVerifier.verify(DependencyVerifie r.java:97) at org.apache.maven.project.Project.verifyDependencies(Project.java:1365 ) at org.apache.maven.plugin.PluginManager.loadScript(PluginManager.java:9 60) at org.apache.maven.plugin.PluginManager.runScript(PluginManager.java:99 3) at org.apache.maven.plugin.PluginManager.initialiseHousingPluginContext( PluginManager.java:706) at org.apache.maven.plugin.PluginManager.prepAttainGoal(PluginManager.ja va:685) at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java: 624) at org.apache.maven.MavenSession.attainGoals(MavenSession.java:266) at org.apache.maven.cli.App.doMain(App.java:486) at org.apache.maven.cli.App.main(App.java:1215) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at com.werken.forehead.Forehead.run(Forehead.java:551) at com.werken.forehead.Forehead.main(Forehead.java:581) Artifact /velocity/jars/velocity-1.4-dev.jar doesn't exists in remote repository , but it exists
[ANN] Maven Ant Plugin 1.8 released
The maven team is pleased to announce the Maven Ant Plugin 1.8 release! http://maven.apache.org/reference/plugins/ant/ Generates ant build files from a maven project, so that plain ant users can build your project Changes in this version include: New Features: o Add ant's setproxy tag. Issue: MPANT-9. Thanks to Jan Nielsen. Fixed bugs: o Use relative paths in directory properties. Issue: MPANT-16. Thanks to Brent Worden. Changes: o Compile tests and run them only if Junit is present in ANT (display a warning otherwise). To automatically install the plugin, type the following on a single line: maven plugin:download -DgroupId=maven -DartifactId=maven-ant-plugin -Dversion=1.8 For a manual installation, you can download the plugin here: http://www.apache.org/dyn/closer.cgi/java-repository/maven/plugins/maven-ant-plugin-1.8.jar Have fun! -The maven team - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-commons-sandbox/sql/lib ant-1.5.jar commons-beanutils-1.6.jar commons-cli-1.0-beta-2.jar commons-betwixt-20030211.133854.jar xml-apis-1.0.b2.jar commons-jelly-20030902.160215.jar hsqldb-1.7.1.jar dom4j-1.4.jar xerces-2.4.0.jar
What was the problem with maven ??
Arnaud
-Message d'origine-
De : Dion Gillard [mailto:[EMAIL PROTECTED]
Envoyé : lundi 19 juillet 2004 08:03
À : Jakarta Commons Developers List
Objet : Re: cvs commit: jakarta-commons-sandbox/sql/lib ant-1.5.jar
commons-beanutils-1.6.jar
commons-cli-1.0-beta-2.jar commons-betwixt-20030211.133854.jar xml-apis-1.0.b2.jar
commons-jelly-
20030902.160215.jar hsqldb-1.7.1.jar dom4j-1.4.jar xerces-2.4.0.jar
Out of curiosity, how are you generating the web site now?
On 17 Jul 2004 10:27:23 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
tomdz 2004/07/17 03:27:23
Modified:sql build.xml .classpath
Added: sql build.properties
sql/lib ant-1.5.jar commons-beanutils-1.6.jar
commons-cli-1.0-beta-2.jar
commons-betwixt-20030211.133854.jar
xml-apis-1.0.b2.jar
commons-jelly-20030902.160215.jar hsqldb-1.7.1.jar
dom4j-1.4.jar xerces-2.4.0.jar ant-optional-1.5.jar
commons-collections-3.0-dev.jar
commons-digester-1.5.jar commons-logging-1.0.3.jar
axion-1.0-M1.jar junit-3.8.1.jar
Removed: sql project.properties maven.xml project.xml
Log:
Build process now uses plain Ant (no maven anymore)
Revision ChangesPath
1.7 +129 -174 jakarta-commons-sandbox/sql/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-commons-sandbox/sql/build.xml,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- build.xml 16 Dec 2003 16:03:07 - 1.6
+++ build.xml 17 Jul 2004 10:27:22 - 1.7
@@ -1,179 +1,134 @@
?xml version=1.0 encoding=UTF-8?
-!--build.xml generated by maven from project.xml version 1.0-dev
- on date December 16 2003, time 0716--
+!--
+/* Copyright 2002-2004 Apache Software Foundation
+ *
+ * Licensed under the Apache License, Version 2.0 (the License);
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an AS IS BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+--
-project default=jar name=commons-sql basedir=.
- property name=defaulttargetdir value=target
- /property
- property name=libdir value=target/lib
- /property
- property name=classesdir value=target/classes
- /property
- property name=testclassesdir value=target/test-classes
- /property
- property name=testreportdir value=target/test-reports
- /property
- property name=distdir value=dist
- /property
- property name=javadocdir value=dist/docs/api
- /property
- property name=final.name value=commons-sql-1.0-dev
- /property
- target name=init description=o Initializes some properties
-mkdir dir=${libdir}
-/mkdir
-condition property=noget
- equals arg2=only arg1=${build.sysclasspath}
- /equals
-/condition
- /target
- target name=compile description=o Compile the code depends=get-deps
-mkdir dir=${classesdir}
-/mkdir
-javac destdir=${classesdir} deprecation=true debug=true
optimize=false
excludes=**/package.html
- src
-pathelement location=src/java
-/pathelement
- /src
- classpath
-fileset dir=${libdir}
- include name=*.jar
- /include
-/fileset
- /classpath
-/javac
- /target
- target name=jar description=o Create the jar depends=compile,test
-jar jarfile=target/${final.name}.jar excludes=**/package.html
basedir=${classesdir}
-/jar
- /target
- target name=clean description=o Clean up the generated directories
-delete dir=${defaulttargetdir}
-/delete
-delete dir=${distdir}
-/delete
- /target
- target name=dist description=o Create a distribution depends=jar,
javadoc
-mkdir dir=dist
-/mkdir
-copy todir=dist
- fileset dir=${defaulttargetdir} includes=*.jar
- /fileset
- fileset dir=${basedir} includes=LICENSE*, README*
- /fileset
-/copy
- /target
- target name=test description=o Run the test cases if=test.failure
depends=internal-
test
-fail message=There were
RE: cvs commit: jakarta-commons-sandbox/workflow build.xml
Hello Craig, I have a good and a bad news. The good is that the problem is fixed in CVS (http://jira.codehaus.org/browse/MPANT-16), but the bad is that the ant plugin wasn't release before maven 1.0. If this bug is really annoying (what I understand) I can publish a new release for the ant plugin. Do you want? Arnaud -Message d'origine- De : Arnaud Heritier [mailto:[EMAIL PROTECTED] Envoyé : jeudi 15 juillet 2004 23:31 À : 'Jakarta Commons Developers List' Objet : RE: cvs commit: jakarta-commons-sandbox/workflow build.xml Ok, Craig I hoped that you used an old release ;-) I will try to found what is happening! Arnaud -Message d'origine- De : Craig McClanahan [mailto:[EMAIL PROTECTED] Envoyé : jeudi 15 juillet 2004 22:41 À : Jakarta Commons Developers List Objet : Re: cvs commit: jakarta-commons-sandbox/workflow build.xml Arnaud Heritier wrote: Hello Craig, Which maven release do you use?? I thought that we fixed this bug!! It seems that you committed some absolute paths! Arnaud I used the 1.0 final release :-(. Reproducible test case -- go to jakarta-commons-sandbox/workflow and run maven ant. Craig - 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: cvs commit: jakarta-commons-sandbox/workflow build.xml
[EMAIL PROTECTED] wrote: Hello Craig, I have a good and a bad news. The good is that the problem is fixed in CVS (http://jira.codehaus.org/browse/MPANT-16), but the bad is that the ant plugin wasn't release before maven 1.0. If this bug is really annoying (what I understand) I can publish a new release for the ant plugin. Do you want? Phew ... at least it wasn't my stupidity :-). ;-) As to what to do, that would seem sort of dependent on how Maven wants to handle updates of plugins. If they are going to have their own separate release cycles, then it would make sense to publish an updated Ant plugin separately (I presume that plugins are versioned like dependencies are, so I can pick the ones I want, right?). If not, you're pretty likely to confuse Maven users if you start publishing individual jars with no version info on top of the 1.0 release. To say nothing of confusing Maven developers when they get a bug report, and have no idea what combination of plugins are actually being used by the reporter. Maven core is published with a set of plugins provided by default. Now that this first release is out, each plugin have their own release cycles. A user can update or add a plugin with a command like : maven plugin:download -DgroupId=group -DartifactId=artifact -Dversion=release In fact, when we have a doubt to reproduce a bug, the developer can ask the user's configuration with the -i option for example. We have regularly some bugs not correctly classified in Jira but we move them ;-) I will propose to the maven team to release the ant plugin. Arnaud. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-commons-sandbox/workflow build.xml
Hello Craig, Which maven release do you use?? I thought that we fixed this bug!! It seems that you committed some absolute paths! Arnaud + property name=defaulttargetdir value=/home/craigmcc/Apache/jakarta-commons- sandbox/workflow/target + /property + property name=libdir value=/home/craigmcc/Apache/jakarta-commons- sandbox/workflow/target/lib + /property + property name=classesdir value=/home/craigmcc/Apache/jakarta-commons- sandbox/workflow/target/classes + /property + property name=testclassesdir value=/home/craigmcc/Apache/jakarta-commons- sandbox/workflow/target/test-classes + /property + property name=testclassesdir value=/home/craigmcc/Apache/jakarta-commons- sandbox/workflow/target/test-classes + /property + property name=testreportdir value=/home/craigmcc/Apache/jakarta-commons- sandbox/workflow/target/test-reports - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-commons-sandbox/workflow build.xml
Ok, Craig I hoped that you used an old release ;-) I will try to found what is happening! Arnaud -Message d'origine- De : Craig McClanahan [mailto:[EMAIL PROTECTED] Envoyé : jeudi 15 juillet 2004 22:41 À : Jakarta Commons Developers List Objet : Re: cvs commit: jakarta-commons-sandbox/workflow build.xml Arnaud Heritier wrote: Hello Craig, Which maven release do you use?? I thought that we fixed this bug!! It seems that you committed some absolute paths! Arnaud I used the 1.0 final release :-(. Reproducible test case -- go to jakarta-commons-sandbox/workflow and run maven ant. Craig - 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: [GUMP][Resources] build file is broken
It was a problem with the ant plugin that we fixed some days ago: http://jira.codehaus.org/browse/MPANT-16 Sorry, Arnaud -Message d'origine- De : Craig McClanahan [mailto:[EMAIL PROTECTED] Envoyé : jeudi 8 juillet 2004 18:47 À : Jakarta Commons Developers List Objet : Re: [GUMP][Resources] build file is broken James Mitchell wrote: I noticed that as it was committed yesterday. Craig, did you mean to check that in as is? Sorry, didn't catch that ... I will manually fix it. FWIW, this was generated with Maven 1.0-rc4, so it sounds like the plugin is still broken. Craig -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - Original Message - From: Stefan Bodewig [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, July 08, 2004 6:37 AM Subject: [GUMP][Resources] build file is broken Hi, the generated build file contains absolute paths pointing to Craig's home dir somewhere. Could anybody please fix it? This is the second time that a Maven generated build file looked wrong in a week. Is the plugin broken that generates them in the latest Maven or are people using an older and broken version? Stefan - 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: [math] Just a test
Same thing for me. I think there are some problems with the mail server. Arnaud -Message d'origine- De : Matthias Wessendorf [mailto:[EMAIL PROTECTED] Envoyé : lundi 24 mai 2004 20:54 À : 'Jakarta Commons Developers List'; [EMAIL PROTECTED] Objet : RE: [math] Just a test jupp, noticed the same ... (today) -Original Message- From: Mark R. Diggory [mailto:[EMAIL PROTECTED] Sent: Monday, May 24, 2004 7:25 PM To: Jakarta Commons Developers List Subject: [math] Just a test Unsure why my email is not coming through. - 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]
