Re: slight problem with testing RC1
[EMAIL PROTECTED] pisze: Grzegorz Kossakowski [EMAIL PROTECTED] writes: I followed your example but still get exactly the same error! Bad news. I have just tried to run it on my Windows XP machine (Java 6) and got the same error. I'll investigate further, today. Thanks for reporting. -- Grzegorz Kossakowski
Re: [test] Cocoon 2.2-RC1 others
Reinhard Poetz pisze:
The proposed release artifacts are available at
http://people.apache.org/builds/cocoon/.
Except for the archetypes the easiest way to test the artifacts is by
adding a
cocoon-staging profile to your ~/.m2/settings.xml:
settings
profiles
profile
idcocoon-staging/id
repositories
repository
idcocoon.staging/id
nameCocoon staging repository/name
urlhttp://people.apache.org/builds/cocoon/url
/repository
/repositories
pluginRepositories
pluginRepository
idcocoon.staging/id
nameCocoon staging repository/name
urlhttp://people.apache.org/builds/cocoon/url
/pluginRepository
/pluginRepositories
/profile
/profiles
/settings
Then change the version number of the artifacts that you use in your POMs
to the number of the proposed artifact and append -P cocoon-staging to
all
your Maven commands, e.g.
mvn install -P cocoon-staging
I really think that creating separate settings file with non-default local repository path is much better option. You don't mess your
original installation, you have clean local repo but do not loose ability to work with other projects, etc. I gave a model file:
http://article.gmane.org/gmane.text.xml.cocoon.devel/73498
Again, make sure that you use the
cocoon-staging profile for all your commands as explained above.
Otherwise the
referenced artifacts can't be found.
There is a problem with dependencies of org.apache.cocoon:cocoon-rcl-webapp-wrapper:1.0.0-M1 that was reported by Joakim Verona. There are
two problems:
1.
http://people.apache.org/builds/cocoon/org/apache/cocoon/cocoon/4/cocoon-4.pom
contains:
dependency
groupIdorg.apache.commons/groupId
artifactIdcommons-jci-fam/artifactId
version1.0-SNAPSHOT/version
/dependency
and it makes Maven going mad. It downloads both (SNAPSHOT and RC) versions but does not use any of them at runtime. I guess we must remove
it, right?
2. I fixed first problem locally and ran mvn jetty:run -X -s
testing-cocoon-settings.xml -X and got:
[INFO] [cocoon:rcl {execution: rcl}]
[INFO] Creating a reloading Cocoon web application.
[INFO] Deploying string-template to WEB-INF/log4j.xml
[DEBUG] unspecified:unspecified:jar:0.0 (selected for null)
[DEBUG] Trying repository cocoon.staging
Downloading:
http://people.apache.org/builds/cocoon/org/apache/cocoon/cocoon-rcl-webapp-wrapper/1.0.0-M1/cocoon-rcl-webapp-wrapper-1.0.0-M1.pom
[...]
4K downloaded
[DEBUG] Artifact resolved
[DEBUG] Retrieving parent-POM: org.apache.cocoon:cocoon-tools-modules::4 for project: null:cocoon-rcl-webapp-wrapper:jar:1.0.0-M1 from the
repository.
[DEBUG] Retrieving parent-POM: org.apache.cocoon:cocoon::4 for project:
null:cocoon-tools-modules:pom:4 from the repository.
[DEBUG] Retrieving parent-POM: org.apache:apache::4 for project:
org.apache.cocoon:cocoon:pom:4 from the repository.
[DEBUG] Adding managed depedendencies for unknown:cocoon-rcl-webapp-wrapper
[...]
[DEBUG] org.apache.cocoon:cocoon-rcl-webapp-wrapper:jar:1.0.0-M1:compile
(selected for compile)
[DEBUG] Trying repository cocoon.staging
Downloading:
http://people.apache.org/builds/cocoon/org/apache/commons/commons-jci-core/1.0-RC1/commons-jci-core-1.0-RC1.pom
[DEBUG] Unable to get resource 'org.apache.commons:commons-jci-core:pom:1.0-RC1' from repository cocoon.staging
(http://people.apache.org/builds/cocoon)
[DEBUG] Trying repository central
Downloading:
http://repo1.maven.org/maven2/org/apache/commons/commons-jci-core/1.0-RC1/commons-jci-core-1.0-RC1.pom
[DEBUG] Unable to get resource
'org.apache.commons:commons-jci-core:pom:1.0-RC1' from repository central
(http://repo1.maven.org/maven2)
[DEBUG] Artifact not found - using stub model: Unable to download the artifact
from any repository
org.apache.commons:commons-jci-core:pom:1.0-RC1
from the specified remote repositories:
cocoon.staging (http://people.apache.org/builds/cocoon),
central (http://repo1.maven.org/maven2)
[DEBUG] Using defaults for missing POM
org.apache.commons:commons-jci-core:pom:1.0-RC1:compile
[DEBUG] org.apache.commons:commons-jci-core:jar:1.0-RC1:compile (selected
for compile)
[DEBUG] commons-logging:commons-logging:jar:1.1:compile (selected for
compile)
[DEBUG] log4j:log4j:jar:1.2.12:compile (selected for compile)
[DEBUG] javax.servlet:servlet-api:jar:2.3:compile (selected for compile)
[DEBUG] log4j:log4j:jar:1.2.12:compile (removed - nearer found: 1.2.14)
[DEBUG] log4j:log4j:jar:1.2.14:compile (selected for compile)
[DEBUG] Trying repository cocoon.staging
Downloading:
http://people.apache.org/builds/cocoon/org/apache/commons/commons-jci-core/1.0-RC1/commons-jci-core-1.0-RC1.jar
[DEBUG] Unable to get resource 'org.apache.commons:commons-jci-core:jar:1.0-RC1' from repository cocoon.staging
(http://people.apache.org/builds/cocoon)
[DEBUG] Trying repository apache-m2-snapshot
Downloading:
Re: [test] Cocoon 2.2-RC1 others
Grzegorz Kossakowski pisze: Reinhard Poetz pisze: POM file of commons-jci-core is not downloaded because apache-m2-snapshot is not used while searching for this pom file. However, when Maven tries to download jar file it uses apache-m2-snpashot repository declared cocoon-rcl-webapp-wrapper. Sight, I spent about two hours to discover things described above to only find out that we again hit this issue: https://issues.apache.org/jira/browse/COCOON-1975 I forgot to say: if you fix first problem and add this: repositories !-- Repository for the commons-jci -- repository idapache-m2-snapshot/id nameApache Maven 2 Repository/name urlhttp://people.apache.org/repo/m2-snapshot-repository/url releases enabledtrue/enabled /releases snapshots enabledfalse/enabled /snapshots /repository /repositories to your block's pom mvn jetty:run works fine. Now it should be clear for you that we hit again COCOON-1975... -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Discussion about Maven
Hello, I talked with Maven developers on IRC today. I asked for the problem[1] we are currently facing. They give me interesting advices and thoughts that may interest you. I paste cleaned up log file of the talk: [15:32:18] grek hi, I'm Grzegorz Kossakowski, a member of PMC of Apache Cocoon [15:33:07] grek I'm looking for help with Maven issues that seem to stop us from releasing artifacts :( [15:34:28] grek being more precise, we are affected by this issue very badly: http://jira.codehaus.org/browse/MNG-2743 [15:35:14] grek Is there anyone eager to help? [16:32:14] wsmoak grek: it's marked for 2.0.4. can you confirm it also happens with 2.0.6 ? [16:33:31] wsmoak and... after a quick read, can you duplicate repository elements where you need them, so you can proceed with the release ? [16:34:01] grek wsmoak: yes, it happens with 2.0.6 [16:35:22] grek wsmoak: yes, we can do this (and done it before) but we have to ask our *users* to put repository elements in *their* poms [16:35:46] grek I'll give you more links explaining the situation [16:36:03] wsmoak so it's not just a problem at release time? [16:36:45] wsmoak why can't the artifacts in that other repo be put in the central repo? [16:37:30] grek they are waiting in your JIRA ready for upload AFAIR ;) ^^ here I confused commons-jci with xreporter artifacts that waited for upload ^^ [16:38:56] grek but the problem still persists, Cocoon has _lots_ of dependencies, some of the stuff is just in between of conversion to the Maven [16:39:05] maxb Isn't central supposed to be selfcontained anyway? [16:39:30] grek what do you mean by self-contained? [16:39:40] wsmoak ok. assuming no problems with the upload bundle and carlos gets them into central, is there still a problem? [16:39:48] jvanzyl if you mean a complete transitive closure, yes but we don't have a way to check just yet [16:40:50] wsmoak poms in the central repo shouldn't define additional repositories [16:41:14] wsmoak it makes users in corporate environments nervous to see Maven trying to download from random places [16:41:28] grek hmmm, good point [16:41:47] grek let me explain our situation and policy at Apache Cocoon [16:42:46] jvanzyl wsmoak: that would be a good rule to check for upload bundles actually [16:42:58] jvanzyl no external repository definitions [16:43:03] * jvanzyl makes a note [16:43:24] grek if we want release something as RC (or final) we have to make sure that we do not depend on snapshot versions and all our dependencies are at central [16:44:22] grek however, we also release milestones which can depend on snapshots and can define it's own repositories (for those unreleased artifacts) [16:45:39] grek and that's the case now, we want to release a milestone of our own Maven plug-in so users can test it and report back if everything works [16:45:50] wsmoak grek: release meaning you want these milestones in the central repo? [16:46:08] grek wsmoak: yes [16:46:28] wsmoak then snapshots simply aren't allowed... you'll have to release milestones of your dependencies. [16:46:49] wsmoak but these aren't really users you're asking to help test, are they? they're more involved than that. [16:47:16] wsmoak what's wrong with staging it on people.apache.org/builds/cocoon and asking them to add a repository to their settings.xml to test ? [16:47:49] grek wsmoak: we have done exactly what you suggest [16:48:08] grek wait a minute, I'll provide links [16:48:48] wsmoak (btw, the Struts PMC has the same policy... snapshot dependencies are allowed in alpha releases.) [16:49:35] grek http://thread.gmane.org/gmane.text.xml.cocoon.devel/73469 and my answers in this thread [16:50:11] grek http://thread.gmane.org/gmane.text.xml.cocoon.devel/73495 - here is the user affected by the MNG-2743 [16:55:13] wsmoak ok. sounds like you're waiting on carlos to close a MAVENUPLOAD issue. [16:56:18] BrianFox grek: you can use the enforcer plugin to make sure people are using 2.0.6 to build cocoon 2.2 [16:56:30] wsmoak Kenney's 2006-01-07 comment on COCOON-1975 sounds right on (and that issue is closed). [16:57:03] grek BrianFox: we use it already, but will it work if someone just uses the artifacts but does not build them? [16:58:26] BrianFox no. I just saw you comment in that thread asking Joakim which version he used. With Enforcer you would know ;-) [16:59:11] BrianFox the prerequisites would affect users of plugins if that's what you mean [17:00:31] grek we require Maven 2.0.6 not only for plug-ins/building but also when people just depend on our artifacts, it's due to dependencyManagment fixed in 2.0.6 [17:00:56] BrianFox i see [17:01:27] wsmoak I don't think you can force them to build their own projects with 2.0.6. [17:01:44] wsmoak you can keep them from using your plugins *unless* they are
Re: slight problem with testing RC1
[EMAIL PROTECTED] pisze: Grzegorz Kossakowski [EMAIL PROTECTED] writes: I followed your example but still get exactly the same error! Joakim, could you please try again with testing-cocoon-settings.xml included below? settings xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd; localRepository/tmp/maven-temp-repository/localRepository profiles profile idtesting-cocoon/id activation activeByDefaulttrue/activeByDefault /activation repositories repository idcocoon.staging/id nameCocoon staging repository/name urlhttp://people.apache.org/builds/cocoon/url /repository !-- Repository for the commons-jci -- repository idapache-m2-snapshot/id nameApache Maven 2 Repository/name urlhttp://people.apache.org/repo/m2-snapshot-repository/url releases enabledtrue/enabled /releases snapshots enabledfalse/enabled /snapshots /repository /repositories pluginRepositories pluginRepository idcocoon.staging/id nameCocoon staging repository/name urlhttp://people.apache.org/builds/cocoon/url /pluginRepository /pluginRepositories /profile /profiles /settings -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: Discussion about Maven
3. We cannot put milestones that depend on snapshot versions on central. It means that we can't upload following artifacts: org.apache.cocoon:cocoon-maven-plugin:1.0.0-M1 org.apache.cocoon:cocoon-rcl-spring-reloader:1.0.0-M1 org.apache.cocoon:cocoon-rcl-webapp-wrapper:1.0.0-M1 If there are people who can vote over on jakarta land ...please do so! The vote for commmons jci rc3 is still open ...but so far I only got only one +1 (that makes two +1s with mine) ...at least not -1s so far. I'd assume that would also help with the release of the above artifacts. A frustrated... -- Torsten
