On 6/24/07, Dennis Lundberg [EMAIL PROTECTED] wrote:
Rahul Akolkar wrote:
On 6/23/07, Phil Steitz [EMAIL PROTECTED] wrote:
On 6/23/07, Rahul Akolkar [EMAIL PROTECTED] wrote:
snip/
I haven't yet understood why we need to release anything from the
sandbox at all. Sure, reproducibility is
any chances of getting this done?
btw I have deployed a snapshot of commons-csv as there was none
already there yet
http://people.apache.org/repo/m2-snapshot-repository/org/apache/commons/commons-csv/
On 4/25/07, Carlos Sanchez [EMAIL PROTECTED] wrote:
then we'd need a release of the parent
the source plugin 2.0.3 was just released, can we go ahead?
On 3/17/07, Niall Pemberton [EMAIL PROTECTED] wrote:
On 3/17/07, Carlos Sanchez [EMAIL PROTECTED] wrote:
can the parent commons-sandbox be released so all sandbox components
can be built by themselves?
it just needs to have
then we'd need a release of the parent and then one of the sandbox parent
On 4/25/07, Niall Pemberton [EMAIL PROTECTED] wrote:
On 4/25/07, Carlos Sanchez [EMAIL PROTECTED] wrote:
the source plugin 2.0.3 was just released, can we go ahead?
I've just updated the commons-parent pom for the 2.0.3
i guess at least to override the repo and prevent releases being deployed
On 4/25/07, Niall Pemberton [EMAIL PROTECTED] wrote:
On 4/26/07, Carlos Sanchez [EMAIL PROTECTED] wrote:
then we'd need a release of the parent and then one of the sandbox parent
Do we need a Sandbox pom any more? Can't
can the parent commons-sandbox be released so all sandbox components
can be built by themselves?
it just needs to have the parent version updated to 2
or even better if commons parent is also released to take advantage of
latest changes before releasing sandbox parent.
--
I could give you my
On 2/14/07, Jörg Schaible [EMAIL PROTECTED] wrote:
Maven should give here better support. If it ever downloads a relocation POM it
should keep the relocation information in a separate DB/storage and take it
always into account when resolving aritfacts no matter which version. Scenario
1 would
place the user needs to change
it by himself if he wants to upgrade. Not any different if an project
changes omain and you have to go to the new one to download it.
On 2/14/07, Jörg Schaible [EMAIL PROTECTED] wrote:
Carlos Sanchez wrote on Wednesday, February 14, 2007 8:40 AM:
iirc you have very
you can change the old poms to relocate to a new location as long as
the new location has the same old jars and poms (just groupId change).
IIRC your case was different.
So, I' see two options for relocation:
1) when new version is out with new groupId add relocation pom in old
location just
has changed
- it'd be better to wait until a major/minor release so users can get
bugfixes easily
On 2/13/07, Carlos Sanchez [EMAIL PROTECTED] wrote:
you can change the old poms to relocate to a new location as long as
the new location has the same old jars and poms (just groupId change).
IIRC your
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 for it or only found
the POM and will update dependencies
am I wrong ?
Nico.
2007/2/13, Carlos Sanchez [EMAIL PROTECTED]:
oh
, and if I update my POM, maven2 will get both
1.1 and 1.2 as they will not be detected as same artifact
This mean a relocated POM for all oldest release is required to avoid
duplicated jars in classpath.
(am I wrong ?)
2007/2/13, Carlos Sanchez [EMAIL PROTECTED]:
scenario 3
iirc you have very different jars in the two groupids, that's not
relocation, that would actually change the binaries for users
On 2/13/07, Jörg Schaible [EMAIL PROTECTED] wrote:
Hi Carlos,
Carlos Sanchez wrote on Tuesday, February 13, 2007 7:29 PM:
you can change the old poms to relocate
as oldGroupId:x
Already in jira, no progress yet
http://jira.codehaus.org/browse/MNG-2316
2007/2/14, Jörg Schaible [EMAIL PROTECTED]:
Hi Carlos,
Carlos Sanchez wrote on Tuesday, February 13, 2007 7:29 PM:
you can change the old poms to relocate to a new location as long as
the new
If it's this one
http://svn.apache.org/viewvc/jakarta/commons/proper/logging/trunk/commons-logging-api.pom?view=markup
I'd remove optional from both dependencies, it's not needed being
scope test or plugins.
So it has no dependencies at all, isn't it?
On 8/10/06, Dennis Lundberg [EMAIL
That commons-discovery-0.2-dev.jar looks like a snapshot to me
On 7/31/06, Henri Yandell [EMAIL PROTECTED] wrote:
On 7/31/06, Rahul Akolkar [EMAIL PROTECTED] wrote:
(moved from user list)
On 7/31/06, Gilles Tabary [EMAIL PROTECTED] wrote:
Hello.
I am building an ear with Maven2. I need
On 7/27/06, Jörg Schaible [EMAIL PROTECTED] wrote:
Arnaud HERITIER wrote on Thursday, July 27, 2006 3:57 PM:
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
I prefer several jars
On 7/27/06, Mario Ivankovits [EMAIL PROTECTED] wrote:
Hi!
Then why not split that further and have
commons-vfs-bz2.jar etc...
Yes, this is something Vincent Massol also told me to do.
The reasons I wanted to go down to two jars are:
*) each jar will have its own release
a commons-attributes plugin, written by (presumable)
Carlos Sanchez (at least
from the website).
http://mojo.codehaus.org/commons-attributes-maven-plugin/
Maybe Carlos is interested to get involved ?
(cc-ed him)
Mvgr,
Martin
Henri Yandell wrote:
On 7/9/06, Leo Sutic [EMAIL PROTECTED] wrote
mmm, were you talking about getting commons-attributes maven 1 plugin
released? the truth is that I never used it
On 7/10/06, Carlos Sanchez [EMAIL PROTECTED] wrote:
It's as easy as adding
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdcommons-attributes-maven-plugin
-attributes)..
Mvgr,
Martin
Carlos Sanchez wrote:
mmm, were you talking about getting commons-attributes maven 1 plugin
released? the truth is that I never used it
On 7/10/06, Carlos Sanchez [EMAIL PROTECTED] wrote:
It's as easy as adding
plugin
groupIdorg.codehaus.mojo
On 7/10/06, Dennis Lundberg [EMAIL PROTECTED] wrote:
Henri Yandell wrote:
On 7/9/06, Leo Sutic [EMAIL PROTECTED] wrote:
Getting 2.2 out would be a nice endcap, and if you could just get the
thing out in accordance with specs, that would be absolutely
fantastic. I'll stick around to get 2.2
Can anyone please add the properties section of the following
dependencies to commons-chain project.xml?
dependency
groupIdjavax.servlet/groupId
artifactIdservlet-api/artifactId
version2.3/version
properties
scopeprovided/scope
/properties
/dependency
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 Loof [EMAIL PROTECTED] wrote:
AFAIK there is a way in maven repo to relocate dependencies, so that a
POM for any commons can be published at commons-xxx
local repo
${user.home}/.m2/repository/... or do I need to use a local httpd
serving as a central repo?
local is ok
--
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
Sources and javadocs are great for maven users because when maven
generates the IDE projects it will check the repo for them, download
and link inside the IDE, enabling debugging through third party
sources or reading the javadocs while coding.
On 5/18/06, Phil Steitz [EMAIL PROTECTED] wrote:
I'm gonna tweak the poms in the repository outside of apache, please
add the optional property in the optional dependencies for future
versions.
I'll take a look to the other jars to make poms.
On 5/15/06, robert burrell donkin [EMAIL PROTECTED] wrote:
On Mon, 2006-05-15 at 20:51 +0200, Dennis
You can remove repositories element from
jakarta/commons/trunks-sandbox/pom.xml and make it inherit from the
apache pom with
parent
groupIdorg.apache/groupId
artifactIdapache/artifactId
version1/version
/parent
On 5/3/06, Henri Yandell [EMAIL PROTECTED] wrote:
I get the following
screw that up?
Hen
On 5/3/06, Carlos Sanchez [EMAIL PROTECTED] wrote:
You can remove repositories element from
jakarta/commons/trunks-sandbox/pom.xml and make it inherit from the
apache pom with
parent
groupIdorg.apache/groupId
artifactIdapache/artifactId
version1/version
I had put them in ibiblio, will be available soon
On 5/2/06, Henri Yandell [EMAIL PROTECTED] wrote:
Downloads okay, though a bit of noise from cookies. Meant increasing
the version that commons-email depends upon (or at least is compiled
against).
Currently the unit tests are hanging though,
On 4/5/06, robert burrell donkin [EMAIL PROTECTED] wrote:
sadly policy dictates that we can't upload release candidates to ibiblio
AFAIK is PMC decision what gets uploaded
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
no, scope is different than optional
properties
optionaltrue/optional
/properties
On 3/23/06, Jörg Schaible [EMAIL PROTECTED] wrote:
Henri Yandell wrote on Thursday, March 23, 2006 9:14 AM:
How do you do that in m1?
properties
scopeoptional/scope
/properties
Exactly! The
This works for me. A known issue it's that it won't work under Mac as
the jdk tools doesn't exist, but I believe it's only needed when
iiop=true
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-antrun-plugin/artifactId
executions
execution
We don't force the package name as groupId, but the expected package
name. eg. junit is in package junit but we'd put it in org.junit.
After that is up to the organization (apache) to decide how org.apache
is splitted.
Now from the apache side ;) sounds like a groupId per PMC is a good
idea, and
I think commons is required or the group would get too big. Also a
groupId per PMC sounds the best approach.
On 3/3/06, Henri Yandell [EMAIL PROTECTED] wrote:
Another one:
org.apache.jakarta
no commons.
With my different hats/mental viewpoints:
* Foundation: We need to have an
You can change that also in the m1 poms. If there're already releases
we can relocate the to the new groupid, so people using the old one
will get a warning althoug still working.
On 2/27/06, Dennis Lundberg [EMAIL PROTECTED] wrote:
Alex Karasulu wrote:
Hiya,
The directory project depends
Thanks Mario,
I'm trying to promote commons-vfs inside maven in the future to
prevent duplicate work and avoid issues like this..
http://jira.codehaus.org/browse/MNG-1047
On 11/27/05, Mario Ivankovits [EMAIL PROTECTED] wrote:
HiCarlos,
At maven project we have a problem with jsch, scp
Hi,
At maven project we have a problem with jsch, scp intermittently
failing with session is down message
http://jira.codehaus.org/browse/MNG-678
Has anyone in vfs experimented this? is the scp vfs support working correctly?
Thanks
Hi,
Please remove commons-logging-1.1-dev.jar from
http://www.apache.org/dist/java-repository/commons-logging/jars/
That place is only for official apache releases. You can use
http://cvs.apache.org/dist/ for nightly builds.
This patch will help in the future
What maven2 tries to address with optional means that there's a very
high chance for that jar not to be needed. Let's say you can use chain
in a standalone (not servlet) environment, then servlet dependency is
optional.
This is a way to solve problems that usually would be easier solved
having a
About adding SNAPSHOT the reason is the same as other people has
already given. I looked in the properties files and tried to guess the
right version which is currently in development, other people will
know better than me. The rule is if last version released was 1.0 it
should be 1.0.1-SNAPSHOT,
. In the other hand IMHO it shouldn't generate a new jar but
depend on the tools.jar, which btw is closer to the approach used in
m2. Anyway we'll have to fix this pom manually when used in the m2
repo.
On 11/8/05, Phil Steitz [EMAIL PROTECTED] wrote:
On 11/8/05, Carlos Sanchez [EMAIL PROTECTED] wrote
(this would be a PITA), or just a mail attachment.
These patches include:
- fixing xml according to schema
- use of version-SNAPSHOT instead of version-dev
- adding some helper tags to improve the m1 pom conversion to m2.
Regards
Carlos Sanchez
/31/05, Dion Gillard [EMAIL PROTECTED] wrote:
Carlos, I think we the developers should work with you on this one.
Post the patch as an attachment here so we can all look at it. How big is it?
On 11/1/05, Carlos Sanchez [EMAIL PROTECTED] wrote:
Hi,
I've been working on fixing the maven
http://issues.apache.org/bugzilla/show_bug.cgi?id=37314
On 10/31/05, Dion Gillard [EMAIL PROTECTED] wrote:
Post away...
On 11/1/05, Carlos Sanchez [EMAIL PROTECTED] wrote:
It's 30KB. I haven't changed dependencies or anything related directly
to the projects and their functionality, mainly
The version should be 1.1-SNAPSHOT or 1.0.1-SNAPSHOT, not -dev.
On 10/23/05, Wendy Smoak [EMAIL PROTECTED] wrote:
The Commons Chain project.xml file still specifies version 1.0. This means
that if you build it locally, Maven will overwrite the official
commons-chain-1.0.jar file in your local
Hi,
The commons beanutils 1.7.0 jar had a incorrect version in the
manifest (1.6). As it seems that there won't be more releases soon, is
it possible to make a 1.7.1 with just the manifest fixed? the number
of people with an incorrect jar would be fewer as they would download
the latest one.
You're right,
http://www.apache.org/dist/java-repository: official releases, mirrored
http://cvs.apache.org/repository/: snapshots and other development
artifacts not released, not mirrored
Regards
On 8/3/05, Dion Gillard [EMAIL PROTECTED] wrote:
Snapshots aren't supposed to go into the
The last commit of the javascript code allows multiple forms on the same
page by generating a unique variable name based on form name, adding this
line
oMinLength = eval('new ' + form.name + '_minlength()');
But if any field of the form is called name javascript validation doesn't
work as
49 matches
Mail list logo
