didn't you ?
2007/4/19, Jörg Schaible <[EMAIL PROTECTED]>:
Hi Niclas,
nicolas de loof wrote on Thursday, April 19, 2007 11:58 AM:
> I'm using JDK 1.3 with M2 with no issue.
> To be clear, I'm TARGETING java 1.3 runtime, but my M2 runs over
> jrockit5. I'm using th
his would require not only the rt.jar but a
fully installed JRE.
If you're interested in such a build process I can give help.
2007/4/19, Emmanuel Bourg <[EMAIL PROTECTED]>:
nicolas de loof a écrit :
> I agrea with Jörg : having some classes depend on java 1.4 should not
make
&g
I'm using JDK 1.3 with M2 with no issue.
To be clear, I'm TARGETING java 1.3 runtime, but my M2 runs over jrockit5.
I'm using the compiler bootclasspath to point to SUN java 1.3 rt.jar to
ensure compatibility.
2007/4/19, Jörg Schaible <[EMAIL PROTECTED]>:
nicolas de l
I agrea with Jörg : having some classes depend on java 1.4 should not make
all the lib depend on java 1.4 when possible. This can be handled in maven2
with some compiler configuration (two executions with includes/excludes),
just by having some naming convention (or deticated package) for java
1.4
p/too snowy (hurts cable for some
reason).
Hen
On 1/16/07, nicolas de loof <[EMAIL PROTECTED]> wrote:
> Can anyone make a release to solve this ?
>
> 2007/1/5, nicolas de loof <[EMAIL PROTECTED]>:
> >
> >
> > The manifest.mf in SVN contain a "Created-B
Sorry, wrong recipient ...
:'-(
Nico.
Le 03/04/07, Antonio Petrelli <[EMAIL PROTECTED]> a écrit :
2007/4/3, nicolas de loof <[EMAIL PROTECTED]>:
> Peux tu compter ça dans ton budget :
>
http://www.camif.fr/wwwSurf/pages/multimedia/OffreDuJour.asp?REFERENCE=883272
&
Peux tu compter ça dans ton budget :
http://www.camif.fr/wwwSurf/pages/multimedia/OffreDuJour.asp?REFERENCE=883272
Ca serait pas mal au fond du placard de l'entrée ?
t.
2007/3/6, Henri Yandell <[EMAIL PROTECTED]>:
On 3/6/07, nicolas de loof <[EMAIL PROTECTED]> wrote:
> I already asked for a 2.2.1 release to remove those "-Extension" in
> manifest, as they break running my app under tomcat 4.
>
> Those libs are only required by t
I already asked for a 2.2.1 release to remove those "-Extension" in
manifest, as they break running my app under tomcat 4.
Those libs are only required by the compiler jar, not the api (runtime) jar,
tho they can be removed from the manifest. This manifest is hand-writen and
is included during th
That would'nt work anyway
If you allready downloaded commons-cc:1.1 and get (maybe transitiviely) a
dependency on org.apache.commons:cc:1.2, you will get both in your classpath
as maven will not kwon those tow groupIds are for the same artifact.
We can't expect maven to reload the 1.1 POM that i
According to this, when relocation projectX for new release N+1
option 1 : making dependency to oldGroupId:N+1 will work, but making
dependency to newGroupId:N+1 will introduce duplicate jars issues if other
dependencies introduce transitive-dependency to oldGroupId:N
option 2 : relocating all P
ll, so users get involved by
having to explicitly change the groupId
On 2/13/07, nicolas de loof <[EMAIL PROTECTED]> wrote:
> I don't understand the distinction you make between scenario 1 and 3 :
>
> if new release use a relocation pom under commons-xxx and DOESN'T deploy
I don't understand the distinction you make between scenario 1 and 3 :
if new release use a relocation pom under commons-xxx and DOESN'T deploy a
jar under this group
- maven2 users will get relocated artifact + a warning to update
dependencies
- maven1 users will not get the new version, may ask
You need to create a relocation POM for the release that does relocation to
avoid hundred users to ask for upload on ibilio.
The relocation POM will produce a warning on console for maven users. You
can expect users to consider warnings and update groupId.
The relocation POM will not be required
I've attached a doc path for howto-filbased.xml that describes
ManagedReloadingStrategy and give a spring-JMX sample.
2007/2/11, nicolas de loof <[EMAIL PROTECTED]>:
OK, I'll look at user guide to add some doc and attach it to Jira.
2007/2/10, Oliver Heger <[EMAIL PROTECTE
[
https://issues.apache.org/jira/browse/CONFIGURATION-237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nicolas de loof updated CONFIGURATION-237:
--
Attachment: howto-filebased.patch
documentation patch
> Cont
OK, I'll look at user guide to add some doc and attach it to Jira.
2007/2/10, Oliver Heger <[EMAIL PROTECTED]>:
nicolas de loof wrote:
> could CONFIGURATION-237 be considered for this release ?
Well, we can add these classes to the release, but I would prefer to
have some more
could CONFIGURATION-237 be considered for this release ?
2007/2/9, Henri Yandell <[EMAIL PROTECTED]>:
1.4 is missing from the downloads page.
Couple of checkstyle errors (no idea if they matter).
Minor nitpick on the Runtime Dependencies page - 'couple' means 2, not 7
:)
Clirr in the xml for
Can anyone make a release to solve this ?
2007/1/5, nicolas de loof <[EMAIL PROTECTED]>:
The manifest.mf in SVN contain a "Created-By: Apache Maven" but I never
got maven include such "Extension-List" in my manifest. The one generated by
the maven build don
="1.4" for the Javac task.
I've trie building with source="1.3" target="1.3" and it passed
Nico.
2007/1/4, Henri Yandell <[EMAIL PROTECTED]>:
On 1/4/07, nicolas de loof <[EMAIL PROTECTED]> wrote:
> According to SVN log, the manifest has been ad
d suggest a new release as compatibility with 1.3 is blocking for me to
upgrade.
Nico.
2007/1/4, Henri Yandell <[EMAIL PROTECTED]>:
On 1/3/07, nicolas de loof <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I'm using commons-attributes with Spring on a Java 1.4 application.
>
Hello,
I'm using commons-attributes with Spring on a Java 1.4 application.
I've included commons-attributes-api 2.2 (from maven repo)
I get this Tomcat exception on startup :
LifecycleException: Missing optional package Extension[ant,
implementationURL= http://www.ibiblio.org/maven/ant/jars/ant
[
http://issues.apache.org/jira/browse/CONFIGURATION-237?page=comments#action_12456318
]
nicolas de loof commented on CONFIGURATION-237:
---
My commons-configuration is build inside Spring context
leases out :)
Hen
On 11/14/06, Nicolas DE LOOF <[EMAIL PROTECTED]> wrote:
Sorry, I didn't read the beginning of this thread.
Do you want to create an Ant build only to ensure compilation for Java
1.3 runtime ?
I'm doing the same with maven by setting the compiler plugin to use
Sorry, I didn't read the beginning of this thread.
Do you want to create an Ant build only to ensure compilation for Java
1.3 runtime ?
I'm doing the same with maven by setting the compiler plugin to use JRE
1.3 rt.jar as bootclasspath. I've made some tests to ensure this
produces java 1.3 co
4) Build under 1.3 using ant, and the site using maven.
Could you please tell me why maven can't be used for building project
for java 1.3 target runtime ?
Nico.
Henri Yandell a écrit :
So... things for a 0.4 release:
1) Add apology+info to release notes/sites concerning 0.3.
2) Fix source
[ http://issues.apache.org/jira/browse/CONFIGURATION-237?page=all ]
nicolas de loof updated CONFIGURATION-237:
--
Attachment: ManagedReloadingStrategyTest.java
A simple testcase.
Some code may be shared with TestFileChangedReloadingStrategy
[
http://issues.apache.org/jira/browse/CONFIGURATION-237?page=comments#action_12449598
]
nicolas de loof commented on CONFIGURATION-237:
---
JMX has multiple way to expose application datas/features. This pacth only
includes a
I've created CONFIGURATION-237 for contributing. The patch adds a
ManagedRealoadingStrategy taht is designed to be exposed as JMX bean to
reload configuration from a JMX console.
Nico.
This message contains information that may be privileged or confidential and is
the property of the Capg
[ http://issues.apache.org/jira/browse/CONFIGURATION-237?page=all ]
nicolas de loof updated CONFIGURATION-237:
--
Attachment: CONFIGURATION-237.patch
> Contrib : managed reloading strat
: Nightly Builds
Reporter: nicolas de loof
Priority: Minor
Attachments: CONFIGURATION-237.patch
This patch adds a reloading strategy based on management request, typically
from a JMX console. The Strategy implements a MBean interface so can be
exported as a JMX Managed
Hello,
I got an issue using Commons-dbcp due to misconfiguration.
The stacktrace doesn't contain the cause exception. As I'm running under
Java5, the "THROWABLE_CAUSE_METHOD" evaluates to true, so the
printStackTrace is not completed by SQLNestedException. But as no one
called the setCause m
I didn't read the start of this topic, but just my 2 cents about
creating more sub-projects for implementation specifics :
You're suggesting to split the project into modules for log4j, avalon
and so on.
Using maven2 you can create those artifacts as POM (not jars) and keep
commons-logging as
Just as a (late) suggestion : would you consider migration to
org.apache.commons groupId ?
(http://maven.apache.org/guides/mini/guide-relocation.html)
Nico.
Henri Yandell a écrit :
4 +1s (including my own...quick +1 for the record).
Leo Sutic
Dennis Lundberg
Stephen Colebourne
Henri Yandel
+1 from a nightly build user.
Henri Yandell a écrit :
This is a vote for releasing Commons Attribetus 2.2 based on RC2.
RC2 is here:
http://people.apache.org/~bayard/commons-attributes
---
[ ] +1 I support this release
[ ] +0
[ ] -0
[ ] -1 I oppose this release because...
-
Commons does not have pom.xml for its components. Them pom files you
find at the repositories (i.e. ibiblio) are converted by a piece of
software from our (Maven 1) project.xml files. This conversion is made
automatically. We are able to add some comments in our project.xml
files to fix some
Hello,
I'm using commons-dbcp on a Java1.3 environment and so I'm required to
recompile it with source modification to comment JDBC3 code.
ant build has a jdbc3 detection task, but maven build has no equivalent.
Maybe a element can be used to add this, but AKAIF
it uses the presence of a cla
k
Cool, I'll have a go at it, to see it I can get it right. It'll have
to wait until this weekend though.
--
Dennis Lundberg
Carlos Sanchez wrote:
> You are right. This would involve copying all the old group sutff to
> the new group and add the relocation poms.
>
> On
AFAIK there is a way in maven repo to "relocate" dependencies, so that a
POM for any commons can be published at commons-xxx groupId, that
"relocates" to org.apache.commons" groupId.
Servletapi for example is now under "javax.servlet"
http://www.ibiblio.org/maven2/servletapi/servletapi/2.4/se
+1 from a 2.2-nightly-build user.
Leo Sutic a écrit :
Hi all,
well, as usual I'm about one year late getting a release out, but I'd
like to release Commons Attributes 2.2. The big changes are:
1. Some bugfixes
2. Support for attribute packages when using maven.
+1 from me.
/LS
--
will run under Java 1.3 without
noSuchMethodException AND uses Java1.4 Stringbuffer optimizations
sebb a écrit :
On 22/05/06, Nicolas De Loof <[EMAIL PROTECTED]> wrote:
>> It is supported in jdk1.3.. Just cast the stringbuffer passed in to
>> an object, so like
>&g
It is supported in jdk1.3.. Just cast the stringbuffer passed in to
an object, so like
StringBuffer.append((Object) StringBuffer)). Much more efficient than
an if...
Surely a StringBuffer is already an Object?
Or am I missing something here?
StringBuffer has a new method in Java 1.4 to a
Where can I find a nightly build of the maven commons-attribute plugin ?
The commons-attributes nightly-build only contains compiler + api
Nicolas De Loof a écrit :
Sorry, I've just discovered this feature is in CVS...
http://jakarta.apache.org/commons/attributes/changelog.html
Nicol
Sorry, I've just discovered this feature is in CVS...
http://jakarta.apache.org/commons/attributes/changelog.html
Nicolas De Loof a écrit :
attributepackages property is used on ant task to allow short
attributes in code.
There is no support for it in the maven plugin. A simple propert
attributepackages property is used on ant task to allow short attributes in
code.
There is no support for it in the maven plugin. A simple property may do the
job.
Nico.
This message contains information that may be privileged or confidential and is
the property of the Capgemini Group. It i
I agree about NOT making non-final jars available on ibiblio (httpclient
beeing an exception)
So could the next RC be uploaded to
http://cvs.apache.org/maven-snapshot-repository/ ?
Please also consider using the new groupId recommandation for apache
commons-X : org.apache.commons.X
Martin
Hello,
Can someone upload commons-logging RC on Maven2 ibiblio repository ?
It would be very cool to also upload a POM and the sources jar...
Nico.
This message contains information that may be privileged or confidential and is
the property of the Capgemini Group. It is intended only for the
Just a cosmetic bug :
AFAIK maven groupId for new version of jakarta commons should be
"org.apache.commons" :
http://maven.apache.org/guides/mini/guide-naming-conventions.html
Nico.
Oliver Heger a écrit :
I tested RC2 with Commons Configuration and did not find any problems
(but this is n
I agree with this : only "required for any use case" dependencies have
to be made non-optional. Without this, transitive dependencies is not a
cool feature anymore and becomes a "-hell".
Well, anything but core dependencies are IMHO optional.
If you decide to make usage of functionality, that
Hello,
I'm using maven2 and commons-configuration, and I need to configure
lot's of as commons-configuration POM declares lot's of
dependencies that are only required for some specialized use-cases.
Those dependencies may be declared as (dom4j, servletapi,
comons-codec...)
Could someone
I think you have to declare mojo snapshot repository in your pom.xml :
http://mojo.codehaus.org/using-sandbox-plugins.html
I myself don't yet use maven2 (just looking at it), so I can't help you.
James Carman a écrit :
Thanks, Jörg. I tried using it, but my M2 installation couldn't download
t
EmailValidator.getInstance().isValid("test@ " + '\t' + "foo.com")
returns "true".
I don't think use of blanks between @ and domain is valid for eMails.
Perhaps SPECIAL_CHARS needs to include blanks ?
Nico.
This message contains information that may be privileged or confidential and i
Can the project.xml be "customized" using jelly ?
something like this :
jdbc
It would be neater if something could be done in the maven.xml to
detect JDK 1.3 and add it into the class path from a property
specified in the build.properties. I'm going to face the same issue in
C
Can't this dependency be solved using jdbc2.0-stdext.jar ? I'm using
Jdk 1.3 and cannot upgrade. Not supporting 1.3 anymore will stop my
migration to commons-configuration.
Nico.
Yes, with jdbc2.0-stdext.jar commons-configuration can be compiled and
run under a JDK 1.3.
Unfortunately t
Mario Ivankovits a écrit :
robert burrell donkin wrote:
There has been no reaction on this vote thread so far.
Will I have to cancel this release because of lack of interest? :-(
3 the release has been compiled using 1.4.2: if commons-configuration is
supposed to support 1.3 jdks then
Hello,
I'm using commons-dbcp in my project running on a JDK 1.3. It requires me to use the commons-dbcp library compiled with 'nojdbc3' option. I'm also using maven to resolve dependencies.
Commons-dbcp jar is available from apache repository (sync with ibiblio), but this is the JDK1.4/jdbc3 v
Hello,
I'm using commons-dbcp in my project running on a JDK 1.3. It requires
me to use the commons-dbcp library compiled with 'nojdbc3' option. I'm
also using maven to resolve dependencies. Commons-dbcp jar is available
from apache repository (sync with ibiblio), but this is the JDK1.4/jdbc3
57 matches
Mail list logo