Andrew Savory wrote:
> Hi,
>
> On 16 Apr 2007, at 12:05, Reinhard Poetz wrote:
>
>> In short, add the commons-jci dependency to the javaflow block only. I
>> don't know if the javaflow-interpreter works then (I guess not) but at
>> least it should fix your build problems.
>
> Ok, I've added it there and it seems to allow the build to succeed. Can
> others more informed on javaflow check there's no problems?
>
well, I don't think I match your description, but I did encounter an
other issue when doing the same kind of build today
> Missing:
> ----------
> 1) org.apache.commons:commons-jci-core:jar:1.0-RC1
>
> Try downloading the file manually from the project website.
>
> Then, install it using the command:
> mvn install:install-file -DgroupId=org.apache.commons
> -DartifactId=commons-jci-core \
> -Dversion=1.0-RC1 -Dpackaging=jar -Dfile=/path/to/file
>
> Path to dependency:
> 1) org.apache.cocoon:cocoon-javaflow-impl:jar:1.0.0-SNAPSHOT
> 2) org.apache.commons:javaflow:jar:1.0-SNAPSHOT
> 3) org.apache.commons:commons-jci-core:jar:1.0-RC1
my analyses:
1.0-RC is not available in the non-snapshot repositories
however, as it doesn't have a 'snapshot' marker in the version name it
is never looked for on other locations
so I had to additionally put in this trick:
[EMAIL
PROTECTED]:~/projects/apache/cocoon-svn/blocks/cocoon-javaflow/cocoon-javaflow-impl$
svn diff
Index: pom.xml
===================================================================
--- pom.xml (revision 529211)
+++ pom.xml (working copy)
@@ -43,6 +43,21 @@
<docs.name>Cocoon JavaFlow</docs.name>
<docs.version>1.0</docs.version>
</properties>
+
+ <repositories>
+ <repository>
+ <id>apache.snapshot</id>
+ <name>Apache Snapshot Repository</name>
+ <url>http://people.apache.org/repo/m2-snapshot-repository</url>
+ <releases>
+ <enabled>true</enabled>
+ </releases>
+ <snapshots>
+ <enabled>true</enabled>
+ </snapshots>
+ </repository>
+ </repositories>
+
<build>
<plugins>
<plugin>
to get things working
the error I got also shows the explicit dependency you're adding should
not be needed since it's recursively called for from the
commons-javaflow pom (which seems to work in my case)
by the way: cocoon-core has a similar setting for getting non snapshots
from apache's m2-snapshot repo, so that is why adding the dependency
there pulled down the 1.0-rc... eventually making it available to
javaflow-impl later on during build...
now, to solve things I think we better
- ask jci peeps to publish non-snapshot releases on a public repo (this
includes RC-releases)
- or just add my patch to the pom, rather then yours, no?
wdyt?
>>> Also, I'm slightly mystified that I seem to be the only one hitting
>>> this. Is no-one else building 2.2?
>>
>> I guess that others who are building 2.2 got the dependency added to
>> the local repos because of building the reloading classloader plugin
>> (trunk/tools/cocoon-rcl) but this is really strange because cocoon-rcl
>> hasn't been added to the default build AFAIK.
>
> <rant>
> This has been bugging me for a long time. It used to be the case that
> people would do clean compiles against clean copies of Cocoon to make
> sure their changes wouldn't impact others (by causing the build to fail,
> for example). Has the move to Maven stopped this from being possible?
> Are people just not bothered about making sure trunk always builds?
> </rant>
>
I hear your pain, but I think this is a consequence of the Snapshot
handling in maven
we've moved away from an own ./lib/**jar section to this new repos
approach with a documented layout serviced by repo-hosts on the web
given the nature of the web this is leading us naturaly into stale-scale
type solutions of various mirrors and caches in the process that are
all making sure the complete build env is not as guaranteed as was the
case with the good ol' massive ./lib/**jar per project in svn
having said that however, good url management in this repo layout DOES
ensure that if you have a file, it will be the same file for anyone (if
you don't have it though look, not unlike you didn't het the complete
lib synced from svn)
helas this good url management does not help us out in those cases where
people are using snapshot dependencies
(theoretically) just removing all snapshots from your local repo should
be enough to bring you into a 'clean' state
(practically) this also means people don't ever go a about changing or
removing non-snapshot-artifactids after being published on a public repo
> Should we come up with some sort of 'community guideline' saying that we
> should clear out our maven repository and do a clean build before
> committing? One person having to go through the loop of downloading and
would be great if dull tasks like this could be handled in an automated
way via something like continuum in stead
> building everything clean is a small price to pay when you consider how
> many people's time could be wasted otherwise. Or is there something else
> we can do to prevent the continual pain of "BUILD FAILED" ?
>
well, to my experience, having your own in house maven2-repo-mirror
helps as well (for one, it makes it easier to just rm -rf that local
repo and get stuff back in fast)
regards,
-marc=
