Jonathan Costers wrote:
One thing we could do more or less now is publish the River artifacts into a
Maven repository somewhere.
We need to confirm the dependencies are correct, no one should need to
depend on the *-dl.jar artefacts, the API that clients and services
depend on are in the platform.jar The *-dl.jar artefacts are free to
change there is no coupling, although we've discussed creating a
Codebase Entry, so the *-dl.jar's can be provisioned.
The *-dl.jar actually depends on the platform.jar and the client and
service also depend on the platform.jar
Basic POMs are already available as well as an Ant target to process them,
we only need details of where to publish the artifacts to.
At least people using Maven in their own projects will be able to easily use
the River artifacts.
We can have Hudson build and publish both stable releases and snapshots,
etc.
We have to sign and vote on the artefacts for stable releases.
River 2.1.2 has been released since approx march. I'm not sure yet
whether the next release will be 2.2.0 or 2.1.3 yet.
Regards,
Peter.
See also:
https://issues.apache.org/jira/browse/RIVER-317
https://issues.apache.org/jira/browse/RIVER-300
2010/8/26 Benson Margulies <[email protected]>
Oh, my, I'm sorry I started this. Look, go ahead, I'd advise, as you
are. Those of you with curiosity can look into maven as used on other
Apache project, and you can consider this alternative some day.
On Thu, Aug 26, 2010 at 5:53 AM, Patricia Shanahan <[email protected]> wrote:
On 8/26/2010 1:59 AM, Sim IJskes - QCG wrote:
On 08/26/2010 10:37 AM, Patrick Wright wrote:
A big advantage of Maven is that all the major Java editors all allow
you to open a project by opening a POM file. All resources, paths,
etc. are immediately configured. This is a big plus for people who
want to explore the code and possibly contribute. Dependency
management is also much more straightforward using Maven.
I dont see a problem with dependency management with the current
situation. If you create a dependency, you should include the stuff you
depend on. A pom file for the final result to use river as a maven
dependency should cause no problems. But we should differentiate between
offering a set of jars with a pom file, and using it for building river
altogether.
As to repeatability, maven is very easy to use when you take the trunk
of a project, but if you want an older version, and rebuild, my personal
experience is that its much harder. When i was bitten by maven, it was
in circumstances where dependencies had disappeared. So my personal
experience proved to me that it is hard for opensource projects to have
the discipline to ensure that one can produce repeatable builds for
older versions at some point in the future.
And thats something i find very important. Or are you saying, ok, as a
developer-user of river, you live with the build of the day, and if you
want to have something stable, you should ensure stable baselines
yourself?
The current situation ensures these stable baselines.
Hmmm. I must admit to a very serious case of Maven-ignorance. Both Ant
and
dear, old, familiar Make allow one to keep the build control files under
revision control along with the thing being built. Is there something
preventing applying that strategy to Maven's control file?
Nailing down when the servicediscovery test regression happened involved
checking out and building about half a dozen intermediate revisions
between
the release that worked and the head revision that failed.
Patricia
