Re: [lang] Junit 3.8.1 vs. 3.8.2
On 1/2/07, Henri Yandell [EMAIL PROTECTED] wrote:
3.8.2 isn'tt available from http://www.ibiblio.org/maven/junit/jars/;
otherwise though - I'm not bothered.
It's there:
$ wget http://www.ibiblio.org/maven/junit/jars/junit-3.8.2.jar
--11:57:53-- http://www.ibiblio.org/maven/junit/jars/junit-3.8.2.jar
= `junit-3.8.2.jar'
Resolving www.ibiblio.org... 152.46.7.80
Connecting to www.ibiblio.org|152.46.7.80|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://mirrors.ibiblio.org/pub/mirrors/maven2/junit/junit/3.8.2/junit-
3.8.2.jar [following]
--11:57:53-- http://mirrors.ibiblio.org/pub/mirrors/maven2/junit/junit/3.8.2/ju
nit-3.8.2.jar
= `junit-3.8.2.jar'
Resolving mirrors.ibiblio.org... 152.46.7.65
Connecting to mirrors.ibiblio.org|152.46.7.65|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 120,640 (118K) [text/plain]
100%[] 120,640 19.83K/sETA 00:00
11:58:00 (19.80 KB/s) - `junit-3.8.2.jar' saved [120640/120640]
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.
But for sure you may add junit/junit/3.8.2 as dependency.
Regards,
Tomek
I'm going to go ahead and do an RC tomorrow - so seems like a bad time
to update our only dependency :)
Hen
On 1/1/07, Gary Gregory [EMAIL PROTECTED] wrote:
Hello All:
The [lang] file default.properties points to Junit 3.8.1.
Is there any reason we should not use the current 3.8.2 version?
Also, the file reads:
junit.jar = ${junit.home}/junit-3.8.1.jar
I would expect it to read:
junit.jar = ${junit.home}/junit.jar
The the jar file Junit delivers is junit.jar.
Gary
-
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: [logging] Using Maven 2 for everything
On 12/30/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Jochen Wiedmann wrote: On 12/30/06, Dennis Lundberg [EMAIL PROTECTED] wrote: 3. The class files in the test jars are different. Out of curiosity: How did you detect that? I wanted to make *really* sure that everything was OK, so I build everything with both Ant and Maven 2. Then I unpacked the jars that were created by each build. After that I used a diff tool [1] to see which files were different. The tool handles binary files as well, but I couldn't see what the difference was. The first thing that sprung to mind was that they had different class versions. So I googled a bit and found this Swing based tool [2] that can tell you the version of a class, among other things. 'javap' utility (part of J2SDK) with '-c -l -s -verbose' arguments provides information about content of 'class' file. I've found it very useful for such checks. Regards, Tomek [1] Araxis Merge, Commercial for Windows only [2] http://sourceforge.net/projects/classeditor/ -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] maven group ids
On 8/21/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Tomasz Pik wrote: Maven won't 'redownload' commons-lang:commons-lang:2.1 and if threre'll be something that depends on org.apache.commons:commons-lang:2.2. Maven won't know that it's only a version difference, for Maven those components are a completly different packages so both will be added to classpath, packaged into wars and so on. And for example for most servlet containers I've observed, that they added jars in alphabetized order, so commons-lang:2.1 will 'win'. Do you have a suggestion for how we should handle this in commons? This cann't be handled/solved in general in commons. My point is that it would be better to avoid some kind of 'propagation' of this problem. Whole disussion starts around new release of commnons-collections which for example depends on commons-lang:2.1 And all I'm suggesting is that those packages should be relocated first, so commons-collections will depend on org.apache.commons:commons-lang:2.1, not commons-lang:commons-lang:2.1. So, if there'll be a org.apache.commons: commons-lang:2.2 and I want to use this because there's something new and neat, I can just add this dependency to my project and this will win over transitive 2.1 depenency from commons-collections. Other solution will be not relocate anything (which probably won't be accepted by repository manages...) or do not define those dependencies in pom.xml files (also not the best solution). One more thing: having this commons-lang:commons-lang:2.1 dependency in org.apache.commons:commons-colletions as a dependency will make a bit strange situation: there'll be a commons package in http://people.apache.org/repo/m2-ibiblio-rsync-repository/ that will depend on other commons project, which is not available there. I know there's a lot of packages, that depends on commons-xx;commons-xx packages (which are on ibiblio) but veryPersonalOpiononIMHO it's not a good situation/veryPersonalOpinion Regards, Tomek snip/ -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] maven group ids
On 8/20/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Tomasz Pik wrote: On 8/16/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Yes, but instead of transiting something, that depends on other commons IMHO something without dependencies should be transited first. In other words, first thing to be done should be a graph of dependencies between various commons packages and those without dependencies should be migrated first. I guess commons-lang is a good candidate here, not configuration that depdends on many other (not migrated yet) components. What would we gain from this? A transition of component A will not include updating existing commons-dependencies in component A to the new ones with the new groupId. That will require a new release of that component A. If fact we don't even have to wait for a release of a component to do this. There is a good reason for *not* picking commons-lang or commons-logging, two components without dependencies on other commons components, as the first component to transition. That is that both are on ibiblio's top 10 downloads list. I had link to it before but can't seem to find it now, sorry. If we do it wrong there then all hell will break loose. It'd be better to choose a medium used component. But this means, that all of those users, that downloading those top10 jars in near future will have obosolete jars. They are *not* obsolete. They are relocated. They still function in exactly the same way as before. The only difference is that there is a relocation section in the pom that indicates to Maven 2 that this project has changed one or more of groupId, artifactId or version. Maven is not re-downloading nonSNAPSHOT artifacts so... Let's imagine I'm a new maven user having project with a dependency on commons-lang:commons-lang-2.1 and maven will download it for me. Some time later this package will be relocated to org.apache.commons.lang:commons-lang:2.1 (or similar). After that there'll be new, let's say acegi v1.4 depending on this 'new' commons-lang (org.apache:commons-lang:2.1) and I need this acegi in my project. So after adding dependency on acegi maven will download org.apache.commons.lang:commons-lang:2.1 and won't download commons-lang:commons-lang:2.1 (which should result as relocation info) and finally, maven will be adding those two commons-lang jars into classpath, copy into WEB-INF/lib and so on. This was one of the tests that I performed when testing this. It is a problem only for Maven 1 which does not handle relocations at all. In Maven 2 this is handled transparently and you will not get two jars in your WEB-INF/lib, only one. All of this till the time I'll manually remove commons-lang:commons-lang:2.1 from my repository so maven will be forced to reload them (and will download relocation info then). It is true that Maven 2 does not re-download something once it has successfully downloaded it, but that has no impact on this discussion. It has some impact for final users... Maven won't 'redownload' commons-lang:commons-lang:2.1 and if threre'll be something that depends on org.apache.commons:commons-lang:2.2. Maven won't know that it's only a version difference, for Maven those components are a completly different packages so both will be added to classpath, packaged into wars and so on. And for example for most servlet containers I've observed, that they added jars in alphabetized order, so commons-lang:2.1 will 'win'. So finally I think that sooner those jars will be relocated there'll be less users having problems like this. As I said before I'm all for a quick transition, but since commons components are very widely used, we have to make sure that we do everything correctly. 100% agree :) Regards, Tomek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] maven group ids
On 8/16/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Yes, but instead of transiting something, that depends on other commons IMHO something without dependencies should be transited first. In other words, first thing to be done should be a graph of dependencies between various commons packages and those without dependencies should be migrated first. I guess commons-lang is a good candidate here, not configuration that depdends on many other (not migrated yet) components. What would we gain from this? A transition of component A will not include updating existing commons-dependencies in component A to the new ones with the new groupId. That will require a new release of that component A. If fact we don't even have to wait for a release of a component to do this. There is a good reason for *not* picking commons-lang or commons-logging, two components without dependencies on other commons components, as the first component to transition. That is that both are on ibiblio's top 10 downloads list. I had link to it before but can't seem to find it now, sorry. If we do it wrong there then all hell will break loose. It'd be better to choose a medium used component. But this means, that all of those users, that downloading those top10 jars in near future will have obosolete jars. Maven is not re-downloading nonSNAPSHOT artifacts so... Let's imagine I'm a new maven user having project with a dependency on commons-lang:commons-lang-2.1 and maven will download it for me. Some time later this package will be relocated to org.apache.commons.lang:commons-lang:2.1 (or similar). After that there'll be new, let's say acegi v1.4 depending on this 'new' commons-lang (org.apache:commons-lang:2.1) and I need this acegi in my project. So after adding dependency on acegi maven will download org.apache.commons.lang:commons-lang:2.1 and won't download commons-lang:commons-lang:2.1 (which should result as relocation info) and finally, maven will be adding those two commons-lang jars into classpath, copy into WEB-INF/lib and so on. All of this till the time I'll manually remove commons-lang:commons-lang:2.1 from my repository so maven will be forced to reload them (and will download relocation info then). So finally I think that sooner those jars will be relocated there'll be less users having problems like this. Regards, Tomek -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] maven group ids
On 8/15/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Rahul Akolkar wrote: On 8/12/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Oliver Heger wrote: Hi, just wanted to ask if there is already a resolution related to the groupIds of commons components. snip/ Everything is set to make the transition to the new groupId. I was hoping that we could use the upcoming release of configuration as the first release with the new groupId. snap/ Do we want to do this? Shouldn't we transition all of Commons together (as Tomasz implies in previous post, and just like we did with the JIRA transition). Suboptimal if folks have to look up which components have migrated yet, there are different groupIds for Commons components in the same POM etc. We should do all of commons, I agree, but I think it would be wise to start with one component and see that everything works as expected. Then we do the rest all in one big transition. Yes, but instead of transiting something, that depends on other commons IMHO something without dependencies should be transited first. In other words, first thing to be done should be a graph of dependencies between various commons packages and those without dependencies should be migrated first. I guess commons-lang is a good candidate here, not configuration that depdends on many other (not migrated yet) components. Regards, Tomek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] maven group ids
Everything is set to make the transition to the new groupId. I was hoping that we could use the upcoming release of configuration as the first release with the new groupId. I will do the necessary work to relocate this and previous releases of configuration, once the release has been made, so that the transition is as transparent as possible to downstream users Configuration depends on many commons components: * commons-collections * commons-lang * commons-logging-api * commons-beanutils-core * commons-codec * commons-jxpath maybe it will be better to relocate them first, make configuration depending on relocated (final?) group/artifact Ids instead of releasing pom, that will depend on something, which will be obsoleted some time later (as I understand, releases of next versions of commons packages will mean 'release new version under new groupId and relocate previous version). just my 5cents, regards, Tomek . Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [exec] Design of commons-exec
On 01/08/05, Niklas Gustavsson [EMAIL PROTECTED] wrote: ... This is a very short description of the cleaned up Ant exec task design: ... * Process destroyer: adds itself as a shutdown hook, Execute adds and removes created processes to ensure that they are correctly destroyed when the JVM stops. I'm sure it works in Ant but I'm worry about using such solution in server-side applications where JVM (in therory) do not stop - just application is being redeployed over and over. Regards, Tomek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] eliminate dependencies on commons-logging [was[beanutils] PROPOSAL: eliminate core dependency on collections
robert burrell donkin wrote:
On 10 May 2004, at 21:26, Stephen Colebourne wrote:
This looks like a very neat solution to the problem to me. The
Class.forName
worries me a little though, as I believe that its not too happy in class
loaders.
it should probably try the context classloader first.
note: it is *very* important to remember that beanutils is used
indirectly by a *very* large user base. (think about the user base for
strut and tomcat at the very least.) i'd be *very* likely to veto any
changes that risk breaking a release without adequate time for testing.
Hmm, Struts is bad example here because it's already using
commons-logging ;)
(it took a lot of work to make commons-logging work anywhere near
reasonably in complex container environments.)
And I'm worry that this will be the same process but code will be split
across different modules.
One more note - I don't know how many 'server applications' are not
using commons-logging, directly or not. Please, take a look at Gump
email and a list of projects depending on o.a.c.l. All of the projects
depending on those projects depends on o.a.c.l.
Also, some recent RIs from Sun using o.a.c.l.
And for them running 'wrapper' around o.a.c.l will be a waste of
force.
Also, o.a.c.l is probably the biggest success of Jakarta Commons team
and I don't think that such solution is the best in the 'marketing'
terms ('whole world using it so we're going not to use it...').
Just my 2cents,
Tomek
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: jakarta-commons-sandbox karma for 'burton'...
Noel J. Bergman wrote: Fascinating ... so it allowed you to create directories without having karma, but it did not allow you to commit files. I wonder if that is a bug. I noticed the same behavior when I was setting up copy of CVSROOT scripts from Apache CVS in my repository. I was thinking that I've made something wrong during setup but looks it's a problem in scripts itself. Regards, Tomek --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] concept proposal: error resort
On 2003-12-11 19:44, Ash .. wrote: The concept of error resort. cut/ A core package, such as lang, will define an interface which has a method like: setErrorResort(int CONSTANT); ErrorResortType extends Enum... setErrorResort(ErrorResortType CONSTANT); ? with constants such as THROW_EXCEPTION, RETURN_NULL, etc defined in the interface and passable to this method. Any class offering the facility of Error Resort will implement this interface and support the method. We could perhaps have other convenience classes to facilitate implementation or the like. But the concept is that, certain classes can choose (rather, their creators) to give the choice of error resort to the users of that class, while hitherto such a thing has always been defined in the class in an iron-clad manner. The idea came to me when I was using ResourceBundle and I wished it returned null instead of throwing the exception when the key is not found. Whether in this case it makes sense or not, I am throwing this idea for debate, and it would be good if a useful addition can be made to the core library here. Maybe I'm missing something but it looks for me that in every method in class implementing ErrorResortInterface you'd like to 'if'/'case' supplied 'constant' and based on this return nonexisting value as null or throwing exception. I'm worry that this makes code a little longer... Something like a proxy over implementation, changing behaviour of some methods? Then you may 'package' every implementation that you know the behaviour (one like Properties, one like ResourceBundle) in the way that your proxy implement. Aspects? HiveMind? Regards, Tomek Waiting for comments, Ash - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] Re: [Math] common-math and bloated 3rd party libraries
Sorry for a little offtopic post. Charles Hudak wrote: I think that this comment is a little shortsighted. We are still using weblogic 5.1 and constantly have problems with the multitude of third party libraries that we are using. WL 5.1 does not seem to find libraries in the WEB-INF/lib directory, as it should, so these have to be set using the classpath. Unfortunately, on Windows NT, the commandline has a size limitation. Every so often, after adding another library, we are unable to start the server due to a the command is too long error. This is a PITA and we have been working around it for several years. Check if your library names contains dots. We've found that something like this-is-a-library-2.1.jar won't work on some versions of WebLogic. After renaming to this-is-a-library-2_1.jar it works. Regards, Tomek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dbutils] Enhanced* classes
David Graham wrote:
The Enhanced* classes don't really seem to be enhanced versions of their
standard counterparts. For example, EnhancedResultSet has this method:
public Long getLongObject(String column) throws SQLException {
return new Long(getLong(column));
}
What about:
public Long getLongObject(String column) throws SQLException {
long result = getLong(column);
if (wasNull()) {
return null;
} else {
return new Long(result);
}
}
How is that enhanced over the standard rs.getObject(col) which performs
automatic type conversions or new Long(rs.getLong(col)) ?
Maybe this method check agains null too?
Regards,
Tomek
David
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [combo] Commons Core release?
Henri Yandell wrote: A url to a build is: http://www.apache.org/~bayard/commons-core/ I'm doing some trickery to turn BeanUtils' commons-logging dependency into a JDK1.4 util.logging dependency. It would be nice to add Pool, HttpClient and maybe Net [with some regexp trickery] and consider that a version 1.0. That's something that I think should be avoided. Combo (IMHO) should be a jar containing classes/resources voted as releases. If developer will pick up Combo described by a list of packages included, (s)he must be sure that Combo jar may be replaced by those packages as they are downloadable jars. With such regexp magic it's not so obvious. Regards, Tomek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [combo] Commons Core release?
Henri Yandell wrote: I figured the munging would be unlikely to pass muster. The easy solution is that BeanUtils/Net are not allowed into a combo-distribution until their dependencies are. So ORO/commons-logging would have to be in it. One problem there is commons-logging's dependency on log4j, logkit and avalon-framework. Two points here; 1. here was a disussion of splitting logging into 'api' and implementation jars but I don't know what's with this idea; 2. it's compile-time dependency rather then runtime; I'm also concerned about recompilation of the code. Note that official release of component comes in source and binary (compiled) version. And sometimes recompilation may make code different (OK, I know, in most cases it's J2SE1.4 problem with StringBuffer.append(StringBuffer) but...). Regards, Tomek I suspect Commons-Regexp [merger of ORO/Regexp] is far more likely to occur and pass the rules I set out than Logging. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [combo] Commons Core release?
A little different idea: How about creating plugin for Maven that will repackage all libraries defined as dependency into one jar? (note problem with MANIFEST file here). Then everybody may create own 'combo' just by writing project.xml file. I know it's different idea then releasing 'combo' as separate package but this will help developers avoid having many jars used in their apps without releasing new combo every new commons core package. And I think that discussion, what should be included in combo will be the longest thread on this list... Regards, Tomek PS There's 'uberjar' plugin but it's working like this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jelly build problems...
Dean Hiller wrote: I downloaded the jelly src 1.0, and maven-1.0-beta-10.zip. When I build I run maven or maven test I get these errors... WARNING: Failed to download jdbc-2.0.jar. Attempting to download jms-1.0.2b.jar. Error retrieving artifact from [http://www.ibiblio.org/maven/jms/jars/jms-1.0.2b cut/ thanks for any pointers or references to more docs, or possible solutions you know of, Sun libraries cannot be stored on ibiblio due to Sun licences. You've to download them from Sun site and put store in your local repository manually. Regards, Tomek PS: http://maven.apache.org/sun-licensing-journey.html Dean - 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: more common classes need a home
Jeffrey Dever wrote: There are still a bunch of classes that are in both HttpClient and Slide. In particular: Base64.java HttpsURL.java HttpURL.java URIException.java URI.java URIUtil.java URLUtil.java Base64 into 'codec' but the rest? commons-net is reserved... in the time of moving from 'sandbox'. Maybe it's a good moment for change from commons-net to commons-protocols? Or maybe those classes should go into commons-lang (another subpackage, lang.net, another long discussion about the scope of lang :-)? -- Regards Tomek Pik Jandalf. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: more common classes need a home
Jeffrey Dever wrote: There are still a bunch of classes that are in both HttpClient and Slide. In particular: Base64.java HttpsURL.java HttpURL.java URIException.java URI.java URIUtil.java URLUtil.java Base64 into 'codec' but the rest? commons-net is reserved... in the time of moving from 'sandbox'. Maybe it's a good moment for change from commons-net to commons-protocols? Or maybe those classes should go into commons-lang (another subpackage, lang.net, another long discussion about the scope of lang :-)? -- Regards Tomek Pik Jandalf. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[morphos] next steps was Re: [morphos] [PATCH] some funcionality
Nicola Ken Barozzi wrote: Tomasz Pik wrote: Ok, all good. Committed. Please check if all is ok. Thanks, I've found a typo somewhere in docs but I'll fix it next patch. Thanks :-) The next step I want to do is to make it possible to use Cocoon Blocks in it as a components drop-in system. It's not so clear to me :-( As always, problem with project dependencies. 1) Morphos depends on Cocoon? 2) Cocoon (in the future) depends on Morphos; ad 2 - I cannot find something like 'cocoon api'. Just huge set of javadocs with everything inside. I'm not too good in Cocoon internals so I don't know where to look for... :-( Right now I'm working (in free time, so I'm not too fast) on JAXP-related classes. -- Regards Tomek Pik [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[morphos] [PATCH] some funcionality
with the
+ *distribution.
+ *
+ * 3. The end-user documentation included with the redistribution, if
+ *any, must include the following acknowlegement:
+ * This product includes software developed by the
+ *Apache Software Foundation (http://www.apache.org/).
+ *Alternately, this acknowlegement may appear in the software itself,
+ *if and wherever such third-party acknowlegements normally appear.
+ *
+ * 4. The names The Jakarta Project, Commons, and Apache Software
+ *Foundation must not be used to endorse or promote products derived
+ *from this software without prior written permission. For written
+ *permission, please contact [EMAIL PROTECTED]
+ *
+ * 5. Products derived from this software may not be called Apache
+ *nor may Apache appear in their names without prior written
+ *permission of the Apache Group.
+ *
+ * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
+ * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
+ * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
+ * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
+ * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
+ * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ *
+ *
+ * This software consists of voluntary contributions made by many
+ * individuals on behalf of the Apache Software Foundation. For more
+ * information on the Apache Software Foundation, please see
+ * http://www.apache.org/.
+ *
+ */
+
+package org.apache.commons.morphos.helpers;
+
+import org.apache.commons.morphos.ObjectFlavor;
+
+/**
+ * Pair of {@link ObjectFlavor} instances.
+ *
+ * Represents possible morphing.
+ *
+ * @author Tomasz Pik
+ * @version $Revision$
+ */
+public class FlavorPair {
+
+private ObjectFlavor input;
+private ObjectFlavor output;
+
+/**
+ * @param input flavor of possible Morpher input
+ * @param output flavor of possible Morpher output
+ */
+public FlavorPair(ObjectFlavor input, ObjectFlavor output) {
+this.input = input;
+this.output = output;
+}
+
+/**
+ * @@return output flavor of pair.
+ */
+public ObjectFlavor getOutputFlavor() {
+return output;
+}
+
+/**
+ * @return input flavor of pair.
+ */
+public ObjectFlavor getInputFlavor() {
+return input;
+}
+}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Morpher] status of the project
Nicola Ken Barozzi wrote: I started to look at Morpher codebase in Jakarta CVS because it looks like something I'm currently looking for. First I'd like to ask, if there's any work on this (it looks like CVS is untouched since some months)? Currently it's not being actively developed, but the reasons why it started are still there and it's still needed. If you want to help-contribute, I'd be very happy :-) First set of thoughts 1 add 'equals' and 'hashCode' to ObjectFlavor to let it works in Maps; 2 add 'registerMorpher(String name, String className, Collection inputFlavors, Collection outputFlavors); to BasicMorpherFactory; 3 add Map that maps every 'registered' input ObjectFlavor to Map which map output ObjectFlavor to morpher name (I believe that there might be a better structure to handle this mapping, right now it's just HashMap); 4 implement getMorpher(ObjectFlavor, ObjectFlavor) using Map from (3) (maybe it should support creating piplelines?); and first question: If Morpher support ObjectFlavors A, B as input and X, Y as output, does it support all possible conversions (A-X, A-Y, B-X, B-Y)? If not, (2) needs to be redefined. If (1)-(4) are acceptable, patch will come. Regards Tomek Pik -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[Morpher] status of the project
Hi, I started to look at Morpher codebase in Jakarta CVS because it looks like something I'm currently looking for. First I'd like to ask, if there's any work on this (it looks like CVS is untouched since some months)? I also want to ask if anybody knows about 'morphers' outisde main Morpher CVS tree (maybe for text/xml+svs - image/* using Batik Transcoder API? Regards Tomek Pik -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
was: [VOTE] moving Jelly to the commons proper
James Strachan wrote: The Jelly code base has been stable for some time and it'd be good to get a stable release of Jelly out so other projects like Maven, Cactus and Latka can depend on a stable, supported release. So I'd like to propose that Jelly be moved to the commons proper where we can start work on getting things in place for an official release. I'm not a commiter, just asking: Will the release contain all tag libraries? I think that it would be better to release Jelly with some tag libraries but maybe not with all of them. And release some tag libraries in the independent way. This 'big' library may be hard to maintain then 'core' distribution and set of tag libraries. (Remember problems with logging Log4J support and NPEs?) I think the same applied to Morper component, BTW. Regards Tomek Pik James -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [lang] ***Utils.classForName( String) ?
Ola Berg wrote: Is the ClassUtils supposed to go into [lang]? If then, yes, if not... I (like java.lang) think that loading class per name is really core. Maybe this ClassUtils will do the same as: http://jakarta.apache.org/commons/discover/apidocs/org/apache/commons/discovery/load/ClassLoaderUtils.html ? Tomek As for better and best... different algorithms in different methods, plus a recommended method that points to any of the former? /O -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [jdbc] JdbcUtil etc
5)
public static Long readLong(ResultSet rs, int index) throws SQLException {
Long result = new Long(rs.getLong(index));
if (rs.wasNull()) {
return null;
} else {
return result;
}
}
public static void setLong(PreparedStatement pstmt, int index, Long value) throws
SQLException {
if (value == null) {
pstmt.setNull(index, Types.NUMBER);
} else {
pstmt.setLong(index, value.longValue();
}
}
And similar methods for the rest of supported types?
Regards
Tomek Pik
[EMAIL PROTECTED]
Hen
--
To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
next possible commons project [regexp]
My summary of the discussion that I started: 1 Many thanks to everybody, who responds; 2 I didn't know about 'pluggable' ORO possibilty, I'll take a look at this (puting something in commons only to have 'commons' in package name is not a good idea); 3 I agree that totally 'bootstraping' funcionality of regexp (like logging) may be dangerous; I was rather thinking about one API for accessing some 'standard' (POSIX, Perl..) regexps in the same way; Something 'pluggable' and having as simple API as possible - in most cases regexp are used (at least by myself) to verifiy given String against given regexp, that's all 4 I know I've seen this before, I know I've seen this before Gotcha: http://jakarta.apache.org/ant/manual/CoreTypes/mapper.html I think I'll try to implement my idea. And, if it'll look interesing, I'll show to commons community. Regards Tomek Pik [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [JJAR] Status? Jar Repository?
Geir Magnusson Jr. wrote: Yes, I did a bit of cleanup that I have to commit. The big change will be the namespace of jar/project names to try and avoid collisions. Two problems that appears during using of JJar: 1 there soluld be a possibility to specify full url to jar file (maybe something like xml:base) 2 there should be a possibility to specify more than one jar file (batik has a lot of jar files). I think a very good example of xml representation of repository is XML Catalogs specification (and xml.commons resolver as an implementation) On the other way, I found that JJar is a very good tool for 'continous integration with ant' developing process. Thanks for this tool. Tomek Pik [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [JJAR] Status? Jar Repository?
Geir Magnusson Jr. wrote: Geir Magnusson Jr. wrote: Two problems that appears during using of JJar: 1 there soluld be a possibility to specify full url to jar file (maybe something like xml:base) Also, when you say 'full URL to JAR file' where do you mean? As I remember it was impossible to specify: jarfile://somewhere/in/filesystem/file1.jar/jar jarhttp://somewhere.over.the.net/file2.jar/jar All files were loaded as thery are located in the same directory as 'repository.xml' or in sub(+)directory of this directory. Tomek -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[Collections] MANIFEST.MF
Hi there, Why there's Implementation-Version: 1.1-dev in 'bin' distribution of Collections 2.0. Regards Tomek Pik [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Logging promo action
Hi there, I have to use FOP and POI in one project. And I've found, that I have to include Avalon LogKit and Log4j - one for FOP and one for POI. Maybe 'Commons' team should take the action of promote Commons Logging through various Jakarta projects as a standard of perfoming loging in the code? Tomek Pik [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [dbcp] JDBC 3.0 and JDK 1.4
otisg wrote: I think this would be a good thing to have in the interim. I'd suggest you post the patches here and hopefully somebody with commit priviledges can apply them. Maybe it will be better to produce two versions of package (JDK 1.4- and JDK 1.4), in the similar to Cactus way (Servlet API 2.2 and Servlet API 2.3). Tomek Pik [EMAIL PROTECTED] Thanks, Otis -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Logging] [VOTE-REDUX] Commons Logging 1.0 Release
Paulo Gaspar wrote: Well, we are deprecating that logger as it puts us (Velocity devs) into the position to have to support every possible app usage of log4j. The replacement just takes a category, so you can configure things in your app as you want (not hope that we provided the configuration options through our properties...) and then have Velocity log directly to that... Good move. That kind of logging config makes more sense on the application (or framework) level than on a library like Velocity. Another way of configure Velocity for log4j: 1 one common log4j.xml config file for the servlet engine - it's admin work to control log levels; 2 every app has its own prefix: 'example_app' for example app know, that this app prefix is 'example_app'; 3 Velocity (static initialization within every web-app) is configured to get from Runtime 'xx.app_name' (xx to avoid problems) key and call Category.getInstance(); with 'xx.app_name.velocity' within our LogSystem implementation. So we can configure different logging level for every application. One (big for me) problem is that log4j during initialization want to make instances of every renderers and layouts so I have to put them into the servlet engine CLASSPATH. Regards Tomasz Pik [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
