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
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 loof wrote on Thursday, April
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
all the lib depend on java 1.4 when possible. This can
?
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 the compiler bootclasspath to point to SUN java
1.3
(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-By: Apache Maven but I
never
got maven include such Extension-List in my
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
Ca serait pas mal au fond du
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 ?
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 the
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 the compiler jar, not the api (runtime)
jar,
tho they can
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
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 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
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
a
jar under this group
- maven2 users will get
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
[
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
Contrib
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 PROTECTED]:
nicolas de loof
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 documentation
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
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't include them. It seems
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 added by bayard. The maven
generated manifest is not used (why ?)
These are for the Ant build - they're the ones that Maven
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.
I've included commons-attributes-api 2.2 (from maven repo)
I get this Tomcat
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://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 :
bean id=configuration class
this will help !
Nico.
Henri Yandell a écrit :
Sorry for not reading this before the other reply Nico.
I'd definitely be interested in how that works, though would be good
to allow the 1.3 certify bit so I can get these releases out :)
Hen
On 11/14/06, Nicolas DE LOOF [EMAIL PROTECTED] wrote
[
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
[ 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
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
: 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
[ http://issues.apache.org/jira/browse/CONFIGURATION-237?page=all ]
nicolas de loof updated CONFIGURATION-237:
--
Attachment: CONFIGURATION-237.patch
Contrib : managed reloading strategy
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
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
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
+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
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 sourceModification element can be used to add this, but AKAIF
it uses
is ok
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 6/7/06, Nicolas De
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
+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
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
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
StringBuffer.append((Object
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
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 property may
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
Nicolas De
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
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 exclusion-hell.
Well, anything but core dependencies are IMHO optional.
If you decide to make usage of
Hello,
I'm using maven2 and commons-configuration, and I need to configure
lot's of exclusion as commons-configuration POM declares lot's of
dependencies that are only required for some specialized use-cases.
Those dependencies may be declared as optional (dom4j, servletapi,
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
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 is
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
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
Can the project.xml be customized using jelly ?
something like this :
j:if test=${java.version == '1.3'}
dependency
idjdbc/id
/dependency
/j:if
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
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
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
56 matches
Mail list logo
