You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Jonathan Costers <jo...@googlemail.com> on 2010/08/26 01:06:31 UTC
Closing out release 2.2.0
Some minor things are left to be done:
- release AR2 in JIRA and give it the name "2.2.0".
- change the version property in common.xml to "2.2.0" in the AR2 branch,
rebuild the AR2 branch and publish the artifacts as the official 2.2.0
release.
- change the version property in common.xml to the next target version in
trunk and highlight it is under development (2.2.1-SNAPSHOT?)
Thoughts?
Jonathan
Re: Closing out release 2.2.0
Posted by Patrick Wright <pd...@gmail.com>.
On Thu, Aug 26, 2010 at 10:59 AM, Sim IJskes - QCG <si...@qcg.nl> 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.
The topic here is building River using Maven (not publishing River
artifacts for a release; that's a separate topic).
It is possible, though not very common as far as I know, to use Maven
but include third-party libraries in the project source tree (for
example in /lib) and configure Maven to look there for the files,
instead of pulling them from a repository. That gives you the utmost
security in rebuilding older versions of the project. I haven't seen
this be necessary though in the Maven projects I've been working with.
It seems more common to rely on the dependency mechanism for
third-party dependencies.
I've seen a great advantage to having Maven POM files available for
open source projects. If they are correctly written (and that's not
that hard), you get started with the project by pointing your editor
to the POM file. Done. Or you go to the command line and type mvn
package or mvn test. Done. This makes the project much more friendly
to newcomers and drive-by hackers, IMO.
I have some free time coming up and maybe I'll just put my money where
my mouth is and post one or more POMs for River to see what people
think.
Regards
Patrick
Re: Closing out release 2.2.0
Posted by Benson Margulies <bi...@gmail.com>.
I just finished working out the technology for that for another project ...
Someone of you should open an INFRA ticket to set up Nexus for River.
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>apache.org</groupId>
<artifactId>sign-and-deploy</artifactId>
<packaging>pom</packaging>
<name>Profiles to run gpg:sign-and-deploy</name>
<version>1</version>
<url>http://www.apache.org</url>
<description>
This pom works as a tool for pushing a release to the Apache Nexus
repository.
Instead of using the 'bundle' mechanism, this signs and pushes
each of the four pieces:
main jar, pom, -sources jar, and -javadoc jar. To use this you
have to have a Maven
settings.xml to configure your credentials on the Apache Nexus
instance, and
to communicate your GPG key and passphrase.
Drop this file into a directory with the pieces, and run mvn -f
THIS_FILE -Ppublish -Dfile=BASE_FILE_NAME
Depending on how you manage your settings.xml, you might have to
activate more profiles.
</description>
<properties>
<url>https://repository.apache.org/service/local/staging/deploy/maven2</url>
</properties>
<profiles>
<profile>
<id>publish</id>
<build>
<defaultGoal>verify</defaultGoal>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-gpg-plugin</artifactId>
<version>1.1</version>
<executions>
<execution>
<id>base</id>
<phase>verify</phase>
<goals>
<goal>sign-and-deploy-file</goal>
</goals>
<configuration>
<file>${file}.jar</file>
<repositoryId>apache.releases.https</repositoryId>
<url>${url}</url>
<pomFile>pom.xml</pomFile>
<keyname>${gpg.keyname}</keyname>
<passphrase>${gpg.passphrase}</passphrase>
</configuration>
</execution>
<execution>
<id>javadoc</id>
<phase>verify</phase>
<goals>
<goal>sign-and-deploy-file</goal>
</goals>
<configuration>
<file>${file}-javadoc.jar</file>
<classifier>javadoc</classifier>
<repositoryId>apache.releases.https</repositoryId>
<url>${url}</url>
<pomFile>pom.xml</pomFile>
<keyname>${gpg.keyname}</keyname>
<passphrase>${gpg.passphrase}</passphrase>
</configuration>
</execution>
<execution>
<id>sources</id>
<phase>verify</phase>
<goals>
<goal>sign-and-deploy-file</goal>
</goals>
<configuration>
<file>${file}-sources.jar</file>
<classifier>sources</classifier>
<repositoryId>apache.releases.https</repositoryId>
<url>${url}</url>
<pomFile>pom.xml</pomFile>
<keyname>${gpg.keyname}</keyname>
<passphrase>${gpg.passphrase}</passphrase>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
</profiles>
</project>
On Thu, Aug 26, 2010 at 8:07 AM, Sim IJskes - QCG <si...@qcg.nl> wrote:
> On 08/26/2010 02:04 PM, Jonathan Costers wrote:
>>
>> One thing we could do more or less now is publish the River artifacts into
>> a
>> Maven repository somewhere.
>> 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.
>
> +1
>
>
Re: Closing out release 2.2.0
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 08/26/2010 02:04 PM, Jonathan Costers wrote:
> One thing we could do more or less now is publish the River artifacts into a
> Maven repository somewhere.
> 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.
+1
Re: Closing out release 2.2.0
Posted by Brian Murphy <bt...@gmail.com>.
On Fri, Aug 27, 2010 at 4:08 AM, Tom Hobbs <tv...@googlemail.com> wrote:
>
> Do you mind if I take your "PS" below and put it onto the River website?
Sure.
Brian
Re: Closing out release 2.2.0
Posted by Tom Hobbs <tv...@googlemail.com>.
Hi Brian,
Do you mind if I take your "PS" below and put it onto the River website?
I'm trying to make the River documentation more comprehensive and I figure
having little tid-bits of knowledge like that on the site will prevent
others having to trawl (seemingly unrelated) mailing list threads to find
them.
Thanks,
Tom
On Thu, Aug 26, 2010 at 5:27 PM, Brian Murphy <bt...@gmail.com>wrote:
> On Thu, Aug 26, 2010 at 8:31 AM, Peter Firmstone <ji...@zeus.net.au> wrote:
>
> no one should need to depend on the *-dl.jar artefacts,
>
>
>
> > he API that clients and services depend on are in the platform.jar The
> > *-dl.jar artefacts are free to change there is no coupling,
>
>
> Peter,
>
> I'm not sure I understand what you mean above. Could you
> explain what you mean regarding the *-dl.jar artifacts?
>
> For what it's worth, from a maven (hopefully someday public)
> repository point of view, the product my company is currently
> working on depends on the following river artifacts:
>
> browser.jar
> classserver.jar
> jsk-lib.jar
> jsk-platform.jar
> jsk-resources.jar
> reggie.jar
> start.jar
> (and hopefully someday outrigger.jar and mahalo.jar)
>
> browser-dl.jar
> jsk-dl.jar
> reggie-dl.jar
> sdm-dl.jar
> (and hopefully someday outrigger-dl.jar and mahalo-dl.jar)
>
> Currently, we have placed the above artifacts in a
> locally maintained maven repository that is updated
> when new versions come out. We would like to someday
> be able to pull these artifacts from a public repository
> that would be automatically updated by the river
> community. So, as you can see, we actually are
> dependent on *-dl.jar files, and we're a bit concerned
> by some of the discussion we've seen from time to
> time regarding re-packaging the jar artifacts (although
> since we're committed to river, I guess we'll just have
> to adjust).
>
> Anyway, with the above in mind, I think you can see
> why your comment about no one depending on *-dl.jar
> artifacts is a bit confusing.
>
> Regards,
> Brian
>
> PS For those who might be wondering about artifacts like
> jini-core.jar, jini-ext.jar, sun-util.jar, etc., although there
> have been previous postings discussing how they are no
> longer needed, it might help some of the new folks on the
> list to hear a repeat of the history of those artifacts; and why
> they should not be used, and why they should probably be
> removed from the build.
>
> Back in the old jini 2.x release time frame, there was quite
> a bit of time and thought put into how the distribution should
> be re-packaged to address deployment issues; for example,
> better modularity, supporting overlays when upgrading, etc.
> That work resulted in the current artifact structure we now see;
> jsk-platform/jsk-lib/jsk-resources/jsk-dl/<service>/<service>-dl.
>
> But because the team did not want to break existing deployments
> that relied on the old jar structure, they decided to also include the
> old artifacts in the release; along with a detailed release note
> explaining the new philosophy and encouraging folks to move to
> the new model, and be prepared for the removal of those old jar
> files down the road. Unfortunately, due to unforeseen events, the
> removal of the old unnecessary jar files never occurred, and people
> seem to still be using them (at least, based on postings on the
> various user lists out there).
>
> With that in mind, one strategy regarding river and maven to
> consider might be that, rather than maven-izing the whole build
> process as the first step (which may be a huge undertaking),
> one might consider first placing the artifacts the current build
> process produces -- minus the unnecessary artifacts described
> above -- into a public maven repository; which is something that
> has been discussed in the past by Jeff Ramsdale and other
> maven experts on this list. This would then make it quite clear
> what jar files are necessary to use river. Additionally, although
> doing this as a first step is aimed at the users of river as opposed
> to river developers/contributors, it still may be a useful thing to
> do with respect to ease-of-use/deployment; and it may actually
> provide a bigger bang for the buck than one might expect.
>
> Anyway, it's just a thought.
>
Maven Artifact's [Was]: Closing out release 2.2.0
Posted by Peter Firmstone <ji...@zeus.net.au>.
Since Maven Artifacts don't allow a URL to be used to uniquely tie the
Codebase to a location, specific to a particular service, we need
another way to prevent different Services from sharing the same
Namespace and to determine which ClassLoader to use for the Service.
I propose we create a new ClassLoader, perhaps called ProxyClassLoader,
that contains the Service's Principal for smart proxy's
This Principal can be used in equals comparisons for ProxyClassLoaders
with identical CodeSources.
The incoming remote thread's Subject can be queried for the Service's
Principal to assist in determining the correct ProxyClassLoader.
Furthermore, the Public Key Certificate can be used as the name for the
Service Principal in large distributed environments.
However there is one more thing I realised, that is Services with
identical signatures (from the same Subject), may serve up different
proxy versions. A ClassLoader can only contain one instance of two
separately versioned proxy CodeSources, this also applies to any
additional CodeSources the proxy depends on, that are also loaded into
the same ClassLoader.
So the other thing that identifies the ClassLoader is the version of the
proxy CodeSource and any additional CodeSource dependencies. Preference
should be given to the proxy version.
Different Proxy versions should have their own namespace (ProxyClassLoader)
Application classes shouldn't be visible to the proxy, only the Service
API, Jini and Java Platforms. (To minimise security risks from
application developers).
Since the locally installed Service API doesn't change, all instances
communicate using the Service API, Jini and Java platform classes.
Thoughts?
Regards,
Peter.
Dennis Reedy wrote:
> On Aug 26, 2010, at 725PM, Peter Firmstone wrote:
>
>
>> Yes, thanks Dennis, that's what I was trying to say ;)
>>
>> Seeing as we've touched on Maven again, is anyone with some Maven experience able to help out with an implementation of Maven Provisioning of proxy jar artifacts. Seeing as everyone is starting to do this I'd like to see a standard way adopted. The proxy jar's can themselves depend on other Jar's since maven can provision those. By provisioning artefacts, it reduces the risk of denial of service.
>>
>
> I dont think we should be concerned about this right now, furthermore, this is generally out of scope [1] for what I think River should be focusing on now, and for the foreseeable future.
>
> What would be more helpful is conventions on how developers that use River and Maven should create their projects. We have had discussions on this in the past (so this is mostly a review), I hope that we can agree on the conventions, document them and eventually create a River archetype that generates a default project structure that produces the requisite artifacts.
>
> We had started out using a Maven-ized classdepandjar (http://www.rio-project.org/classdepandjar-mojo.html), allowing the creation of multiple artifacts from a single project (service.jar, service-dl.jar, service-ui.jar, etc....). While this worked, the pom became overly complicated, the approach became confusing, especially if one of the artifacts had dependencies that the others didnt.
>
> What we have moved to (and I think this is common across other developers) is to create a multi-module project that reflects the basic architectural elements of a River service. Basically, a River service is composed of the following modules:
>
> some-service\
> api\
> *proxy\
> *ui\
> service\
>
> * = optional
>
> The api module contains all the classes (interfaces and other classes) that is needed to communicate with the service
> The proxy module (optional), depends on the api module, and provides smart proxy support
> The ui module (optional), depends on the api module and provides support for a service user interface
> The service module, depends on the api module (or proxy module if used) provides the backend service implementation.
>
> Using this approach produces an easy to use and understandable model, doesnt require classdepandjar, and dependency management is handled quite cleanly. Some will argue on the names of the modules, it doesnt really matter what the names are, as long as the project has its constituent elements broken out.
>
> Maven groupId and artifactId conventions we adopted are as follows:
>
> com.foo:some-service:version
> com.foo.some-service:api:version
> com.foo.some-service:proxy:version
> com.foo.some-service:ui:version
> com.foo.some-service:service:version
>
> Additionally, if I wanted to use a service (as a client) I would declare a dependency on com.foo.some-service:api:version
>
> I hope this helps, and I do think if we can agree on conventions like this, document them, and produce a simple example that uses them, it will help developers use River and Maven.
>
> Dennis
>
> [1] Higher level frameworks like Rio have this capability.
>
>
>
Re: Closing out release 2.2.0
Posted by Peter Firmstone <ji...@zeus.net.au>.
Dennis Reedy wrote:
> On Aug 26, 2010, at 725PM, Peter Firmstone wrote:
>
>
>> Yes, thanks Dennis, that's what I was trying to say ;)
>>
>> Seeing as we've touched on Maven again, is anyone with some Maven experience able to help out with an implementation of Maven Provisioning of proxy jar artifacts. Seeing as everyone is starting to do this I'd like to see a standard way adopted. The proxy jar's can themselves depend on other Jar's since maven can provision those. By provisioning artefacts, it reduces the risk of denial of service.
>>
>
> I dont think we should be concerned about this right now, furthermore, this is generally out of scope [1] for what I think River should be focusing on now, and for the foreseeable future.
>
> What would be more helpful is conventions on how developers that use River and Maven should create their projects. We have had discussions on this in the past (so this is mostly a review), I hope that we can agree on the conventions, document them and eventually create a River archetype that generates a default project structure that produces the requisite artifacts.
>
> We had started out using a Maven-ized classdepandjar (http://www.rio-project.org/classdepandjar-mojo.html), allowing the creation of multiple artifacts from a single project (service.jar, service-dl.jar, service-ui.jar, etc....). While this worked, the pom became overly complicated, the approach became confusing, especially if one of the artifacts had dependencies that the others didnt.
>
> What we have moved to (and I think this is common across other developers) is to create a multi-module project that reflects the basic architectural elements of a River service. Basically, a River service is composed of the following modules:
>
> some-service\
> api\
> *proxy\
> *ui\
> service\
>
> * = optional
>
> The api module contains all the classes (interfaces and other classes) that is needed to communicate with the service
> The proxy module (optional), depends on the api module, and provides smart proxy support
> The ui module (optional), depends on the api module and provides support for a service user interface
> The service module, depends on the api module (or proxy module if used) provides the backend service implementation.
>
> Using this approach produces an easy to use and understandable model, doesnt require classdepandjar, and dependency management is handled quite cleanly. Some will argue on the names of the modules, it doesnt really matter what the names are, as long as the project has its constituent elements broken out.
>
> Maven groupId and artifactId conventions we adopted are as follows:
>
> com.foo:some-service:version
> com.foo.some-service:api:version
> com.foo.some-service:proxy:version
> com.foo.some-service:ui:version
> com.foo.some-service:service:version
>
> Additionally, if I wanted to use a service (as a client) I would declare a dependency on com.foo.some-service:api:version
>
> I hope this helps, and I do think if we can agree on conventions like this, document them, and produce a simple example that uses them, it will help developers use River and Maven.
>
> Dennis
>
> [1] Higher level frameworks like Rio have this capability.
>
>
>
Can you add this (edit) to the document at
https://issues.apache.org/jira/secure/ManageAttachments.jspa?id=12465786
Got any advise on how to handle message digests?
Peter.
Re: Closing out release 2.2.0
Posted by Patrick Wright <pd...@gmail.com>.
> The point here is to first provide conventions for developers that use Maven to be able to easily create and start services that use River.
That is a good goal, yes.
>> The client should have an easy way to get at the API jars,
>> yes, but the client will also need access to the DL jars at runtime.
>> They shouldn't have to download the same jar files again and again.
>> Maven has the advantage of having active development, a known and
>> fairly straightforward repository structure, etc. so that's been
>> proposed for part of the implementation.
>
> And I was all for that when we discussed it, and I dont think it needs to be part of closing out release 2.2.0.
You are right, it does not. The thread has gotten a bit messy, I
apologize if I misunderstood.
Patrick
Re: Closing out release 2.2.0
Posted by Dennis Reedy <de...@gmail.com>.
On Aug 27, 2010, at 1225PM, Patrick Wright wrote:
>>> Seeing as we've touched on Maven again, is anyone with some Maven experience able to help out with an implementation of Maven Provisioning of proxy jar artifacts. Seeing as everyone is starting to do this I'd like to see a standard way adopted. The proxy jar's can themselves depend on other Jar's since maven can provision those. By provisioning artefacts, it reduces the risk of denial of service.
>>
>> I dont think we should be concerned about this right now, furthermore, this is generally out of scope [1] for what I think River should be focusing on now, and for the foreseeable future.
>>
>> What would be more helpful is conventions on how developers that use River and Maven should create their projects. We have had discussions on this in the past (so this is mostly a review), I hope that we can agree on the conventions, document them and eventually create a River archetype that generates a default project structure that produces the requisite artifacts.
>
> There are different issues being addressed here. With the current
> River system, I have no easy way to say, "this service's DL jars
> haven't been changed in while, so if you have a local copy that
> matches this checksum, use it and skip the download." That's was the
> point of having a service be able to provide a Maven (or similar)
> coordinate identifying the DL jar(s), possibly along with a checksum,
> that you need to use the service.
>
> This is orthogonal to the question of how to easily package a River
> service.
The point here is to first provide conventions for developers that use Maven to be able to easily create and start services that use River.
> The client should have an easy way to get at the API jars,
> yes, but the client will also need access to the DL jars at runtime.
> They shouldn't have to download the same jar files again and again.
> Maven has the advantage of having active development, a known and
> fairly straightforward repository structure, etc. so that's been
> proposed for part of the implementation.
And I was all for that when we discussed it, and I dont think it needs to be part of closing out release 2.2.0.
Re: Closing out release 2.2.0
Posted by Patrick Wright <pd...@gmail.com>.
>> Seeing as we've touched on Maven again, is anyone with some Maven experience able to help out with an implementation of Maven Provisioning of proxy jar artifacts. Seeing as everyone is starting to do this I'd like to see a standard way adopted. The proxy jar's can themselves depend on other Jar's since maven can provision those. By provisioning artefacts, it reduces the risk of denial of service.
>
> I dont think we should be concerned about this right now, furthermore, this is generally out of scope [1] for what I think River should be focusing on now, and for the foreseeable future.
>
> What would be more helpful is conventions on how developers that use River and Maven should create their projects. We have had discussions on this in the past (so this is mostly a review), I hope that we can agree on the conventions, document them and eventually create a River archetype that generates a default project structure that produces the requisite artifacts.
There are different issues being addressed here. With the current
River system, I have no easy way to say, "this service's DL jars
haven't been changed in while, so if you have a local copy that
matches this checksum, use it and skip the download." That's was the
point of having a service be able to provide a Maven (or similar)
coordinate identifying the DL jar(s), possibly along with a checksum,
that you need to use the service.
This is orthogonal to the question of how to easily package a River
service. The client should have an easy way to get at the API jars,
yes, but the client will also need access to the DL jars at runtime.
They shouldn't have to download the same jar files again and again.
Maven has the advantage of having active development, a known and
fairly straightforward repository structure, etc. so that's been
proposed for part of the implementation.
Regards
Patrick
Re: Closing out release 2.2.0
Posted by Dennis Reedy <de...@gmail.com>.
On Aug 27, 2010, at 1118AM, Benson Margulies wrote:
> It looks like you're looking for an archtetype, but I don't even know
> if there is such a thing as a multi-module archtetype!
Sure there is. I've already created one for Rio that generates the project structure below. If you'd like more info, look here http://maven.apache.org/archetype/maven-archetype-plugin/examples/create-multi-module-project.html
HTH
Dennis
Re: Closing out release 2.2.0
Posted by Benson Margulies <bi...@gmail.com>.
It looks like you're looking for an archtetype, but I don't even know
if there is such a thing as a multi-module archtetype!
On Fri, Aug 27, 2010 at 11:13 AM, Dennis Reedy <de...@gmail.com> wrote:
>
> On Aug 26, 2010, at 725PM, Peter Firmstone wrote:
>
>> Yes, thanks Dennis, that's what I was trying to say ;)
>>
>> Seeing as we've touched on Maven again, is anyone with some Maven experience able to help out with an implementation of Maven Provisioning of proxy jar artifacts. Seeing as everyone is starting to do this I'd like to see a standard way adopted. The proxy jar's can themselves depend on other Jar's since maven can provision those. By provisioning artefacts, it reduces the risk of denial of service.
>
> I dont think we should be concerned about this right now, furthermore, this is generally out of scope [1] for what I think River should be focusing on now, and for the foreseeable future.
>
> What would be more helpful is conventions on how developers that use River and Maven should create their projects. We have had discussions on this in the past (so this is mostly a review), I hope that we can agree on the conventions, document them and eventually create a River archetype that generates a default project structure that produces the requisite artifacts.
>
> We had started out using a Maven-ized classdepandjar (http://www.rio-project.org/classdepandjar-mojo.html), allowing the creation of multiple artifacts from a single project (service.jar, service-dl.jar, service-ui.jar, etc....). While this worked, the pom became overly complicated, the approach became confusing, especially if one of the artifacts had dependencies that the others didnt.
>
> What we have moved to (and I think this is common across other developers) is to create a multi-module project that reflects the basic architectural elements of a River service. Basically, a River service is composed of the following modules:
>
> some-service\
> api\
> *proxy\
> *ui\
> service\
>
> * = optional
>
> The api module contains all the classes (interfaces and other classes) that is needed to communicate with the service
> The proxy module (optional), depends on the api module, and provides smart proxy support
> The ui module (optional), depends on the api module and provides support for a service user interface
> The service module, depends on the api module (or proxy module if used) provides the backend service implementation.
>
> Using this approach produces an easy to use and understandable model, doesnt require classdepandjar, and dependency management is handled quite cleanly. Some will argue on the names of the modules, it doesnt really matter what the names are, as long as the project has its constituent elements broken out.
>
> Maven groupId and artifactId conventions we adopted are as follows:
>
> com.foo:some-service:version
> com.foo.some-service:api:version
> com.foo.some-service:proxy:version
> com.foo.some-service:ui:version
> com.foo.some-service:service:version
>
> Additionally, if I wanted to use a service (as a client) I would declare a dependency on com.foo.some-service:api:version
>
> I hope this helps, and I do think if we can agree on conventions like this, document them, and produce a simple example that uses them, it will help developers use River and Maven.
>
> Dennis
>
> [1] Higher level frameworks like Rio have this capability.
>
>
Re: Closing out release 2.2.0
Posted by Dennis Reedy <de...@gmail.com>.
On Aug 26, 2010, at 725PM, Peter Firmstone wrote:
> Yes, thanks Dennis, that's what I was trying to say ;)
>
> Seeing as we've touched on Maven again, is anyone with some Maven experience able to help out with an implementation of Maven Provisioning of proxy jar artifacts. Seeing as everyone is starting to do this I'd like to see a standard way adopted. The proxy jar's can themselves depend on other Jar's since maven can provision those. By provisioning artefacts, it reduces the risk of denial of service.
I dont think we should be concerned about this right now, furthermore, this is generally out of scope [1] for what I think River should be focusing on now, and for the foreseeable future.
What would be more helpful is conventions on how developers that use River and Maven should create their projects. We have had discussions on this in the past (so this is mostly a review), I hope that we can agree on the conventions, document them and eventually create a River archetype that generates a default project structure that produces the requisite artifacts.
We had started out using a Maven-ized classdepandjar (http://www.rio-project.org/classdepandjar-mojo.html), allowing the creation of multiple artifacts from a single project (service.jar, service-dl.jar, service-ui.jar, etc....). While this worked, the pom became overly complicated, the approach became confusing, especially if one of the artifacts had dependencies that the others didnt.
What we have moved to (and I think this is common across other developers) is to create a multi-module project that reflects the basic architectural elements of a River service. Basically, a River service is composed of the following modules:
some-service\
api\
*proxy\
*ui\
service\
* = optional
The api module contains all the classes (interfaces and other classes) that is needed to communicate with the service
The proxy module (optional), depends on the api module, and provides smart proxy support
The ui module (optional), depends on the api module and provides support for a service user interface
The service module, depends on the api module (or proxy module if used) provides the backend service implementation.
Using this approach produces an easy to use and understandable model, doesnt require classdepandjar, and dependency management is handled quite cleanly. Some will argue on the names of the modules, it doesnt really matter what the names are, as long as the project has its constituent elements broken out.
Maven groupId and artifactId conventions we adopted are as follows:
com.foo:some-service:version
com.foo.some-service:api:version
com.foo.some-service:proxy:version
com.foo.some-service:ui:version
com.foo.some-service:service:version
Additionally, if I wanted to use a service (as a client) I would declare a dependency on com.foo.some-service:api:version
I hope this helps, and I do think if we can agree on conventions like this, document them, and produce a simple example that uses them, it will help developers use River and Maven.
Dennis
[1] Higher level frameworks like Rio have this capability.
Re: Closing out release 2.2.0
Posted by Peter Firmstone <ji...@zeus.net.au>.
Yes, thanks Dennis, that's what I was trying to say ;)
Seeing as we've touched on Maven again, is anyone with some Maven
experience able to help out with an implementation of Maven Provisioning
of proxy jar artifacts. Seeing as everyone is starting to do this I'd
like to see a standard way adopted. The proxy jar's can themselves
depend on other Jar's since maven can provision those. By provisioning
artefacts, it reduces the risk of denial of service.
Patrick proposed an Entry format for the download jar's.
N.B. We've got a draft up for review about archive names and API
Evolution on JIRA River-341.
We also need a URL format and handler for Maven archives, I noticed that
mvn:// isn't quite right since it doesn't include the version
information or a checksum for integrity, perhaps someone can elaborate,
I don't want the URL to be location dependant, rather it should be name,
version and checksum dependant. This makes CodeSources with identical
jar archives, identical, rather than different, simply because they were
downloaded from different servers. It also could eliminate codebase
annotation loss. This change would improve reliability.
https://issues.apache.org/jira/secure/ManageAttachments.jspa?id=12465786
Thanks,
Peter.
Dennis Reedy wrote:
> Hi Brian,
>
> I think Peter is referring to an earlier discussion that surrounded adding specific <dependency> declarations in your pom for -dl.jar artifacts. The discussion centered on breaking out a Jini service's constituent architectural elements, where a service creates an API (interfaces and any classes required to communicate with the service), a DL that contains any proxy classes and other details the service's proxy requires, and of the course the impl. Any client will only need to declare a dependency on the API, never the DL.
>
> From a Maven point of view you're absolutely correct, you'll need to push these artifacts up.
>
> Regards
>
> Dennis
>
> On Aug 26, 2010, at 1227PM, Brian Murphy wrote:
>
>
>> On Thu, Aug 26, 2010 at 8:31 AM, Peter Firmstone <ji...@zeus.net.au> wrote:
>>
>> no one should need to depend on the *-dl.jar artefacts,
>>
>>
>>
>>
>>> he API that clients and services depend on are in the platform.jar The
>>> *-dl.jar artefacts are free to change there is no coupling,
>>>
>> Peter,
>>
>> I'm not sure I understand what you mean above. Could you
>> explain what you mean regarding the *-dl.jar artifacts?
>>
>> For what it's worth, from a maven (hopefully someday public)
>> repository point of view, the product my company is currently
>> working on depends on the following river artifacts:
>>
>> browser.jar
>> classserver.jar
>> jsk-lib.jar
>> jsk-platform.jar
>> jsk-resources.jar
>> reggie.jar
>> start.jar
>> (and hopefully someday outrigger.jar and mahalo.jar)
>>
>> browser-dl.jar
>> jsk-dl.jar
>> reggie-dl.jar
>> sdm-dl.jar
>> (and hopefully someday outrigger-dl.jar and mahalo-dl.jar)
>>
>> Currently, we have placed the above artifacts in a
>> locally maintained maven repository that is updated
>> when new versions come out. We would like to someday
>> be able to pull these artifacts from a public repository
>> that would be automatically updated by the river
>> community. So, as you can see, we actually are
>> dependent on *-dl.jar files, and we're a bit concerned
>> by some of the discussion we've seen from time to
>> time regarding re-packaging the jar artifacts (although
>> since we're committed to river, I guess we'll just have
>> to adjust).
>>
>> Anyway, with the above in mind, I think you can see
>> why your comment about no one depending on *-dl.jar
>> artifacts is a bit confusing.
>>
>> Regards,
>> Brian
>>
>> PS For those who might be wondering about artifacts like
>> jini-core.jar, jini-ext.jar, sun-util.jar, etc., although there
>> have been previous postings discussing how they are no
>> longer needed, it might help some of the new folks on the
>> list to hear a repeat of the history of those artifacts; and why
>> they should not be used, and why they should probably be
>> removed from the build.
>>
>> Back in the old jini 2.x release time frame, there was quite
>> a bit of time and thought put into how the distribution should
>> be re-packaged to address deployment issues; for example,
>> better modularity, supporting overlays when upgrading, etc.
>> That work resulted in the current artifact structure we now see;
>> jsk-platform/jsk-lib/jsk-resources/jsk-dl/<service>/<service>-dl.
>>
>> But because the team did not want to break existing deployments
>> that relied on the old jar structure, they decided to also include the
>> old artifacts in the release; along with a detailed release note
>> explaining the new philosophy and encouraging folks to move to
>> the new model, and be prepared for the removal of those old jar
>> files down the road. Unfortunately, due to unforeseen events, the
>> removal of the old unnecessary jar files never occurred, and people
>> seem to still be using them (at least, based on postings on the
>> various user lists out there).
>>
>> With that in mind, one strategy regarding river and maven to
>> consider might be that, rather than maven-izing the whole build
>> process as the first step (which may be a huge undertaking),
>> one might consider first placing the artifacts the current build
>> process produces -- minus the unnecessary artifacts described
>> above -- into a public maven repository; which is something that
>> has been discussed in the past by Jeff Ramsdale and other
>> maven experts on this list. This would then make it quite clear
>> what jar files are necessary to use river. Additionally, although
>> doing this as a first step is aimed at the users of river as opposed
>> to river developers/contributors, it still may be a useful thing to
>> do with respect to ease-of-use/deployment; and it may actually
>> provide a bigger bang for the buck than one might expect.
>>
>> Anyway, it's just a thought.
>>
>
>
>
Re: Closing out release 2.2.0
Posted by Jonathan Costers <jo...@googlemail.com>.
>
>
> With that in mind, one strategy regarding river and maven to
> consider might be that, rather than maven-izing the whole build
> process as the first step (which may be a huge undertaking),
> one might consider first placing the artifacts the current build
> process produces -- minus the unnecessary artifacts described
> above -- into a public maven repository; which is something that
> has been discussed in the past by Jeff Ramsdale and other
> maven experts on this list. This would then make it quite clear
> what jar files are necessary to use river. Additionally, although
> doing this as a first step is aimed at the users of river as opposed
> to river developers/contributors, it still may be a useful thing to
> do with respect to ease-of-use/deployment; and it may actually
> provide a bigger bang for the buck than one might expect.
>
> Anyway, it's just a thought.
>
Thank you. That is exactly what I meant above as well.
As a first step, try to get the artifacts into a public repository.
Re: Closing out release 2.2.0
Posted by Dennis Reedy <de...@gmail.com>.
Hi Brian,
I think Peter is referring to an earlier discussion that surrounded adding specific <dependency> declarations in your pom for -dl.jar artifacts. The discussion centered on breaking out a Jini service's constituent architectural elements, where a service creates an API (interfaces and any classes required to communicate with the service), a DL that contains any proxy classes and other details the service's proxy requires, and of the course the impl. Any client will only need to declare a dependency on the API, never the DL.
From a Maven point of view you're absolutely correct, you'll need to push these artifacts up.
Regards
Dennis
On Aug 26, 2010, at 1227PM, Brian Murphy wrote:
> On Thu, Aug 26, 2010 at 8:31 AM, Peter Firmstone <ji...@zeus.net.au> wrote:
>
> no one should need to depend on the *-dl.jar artefacts,
>
>
>
>> he API that clients and services depend on are in the platform.jar The
>> *-dl.jar artefacts are free to change there is no coupling,
>
>
> Peter,
>
> I'm not sure I understand what you mean above. Could you
> explain what you mean regarding the *-dl.jar artifacts?
>
> For what it's worth, from a maven (hopefully someday public)
> repository point of view, the product my company is currently
> working on depends on the following river artifacts:
>
> browser.jar
> classserver.jar
> jsk-lib.jar
> jsk-platform.jar
> jsk-resources.jar
> reggie.jar
> start.jar
> (and hopefully someday outrigger.jar and mahalo.jar)
>
> browser-dl.jar
> jsk-dl.jar
> reggie-dl.jar
> sdm-dl.jar
> (and hopefully someday outrigger-dl.jar and mahalo-dl.jar)
>
> Currently, we have placed the above artifacts in a
> locally maintained maven repository that is updated
> when new versions come out. We would like to someday
> be able to pull these artifacts from a public repository
> that would be automatically updated by the river
> community. So, as you can see, we actually are
> dependent on *-dl.jar files, and we're a bit concerned
> by some of the discussion we've seen from time to
> time regarding re-packaging the jar artifacts (although
> since we're committed to river, I guess we'll just have
> to adjust).
>
> Anyway, with the above in mind, I think you can see
> why your comment about no one depending on *-dl.jar
> artifacts is a bit confusing.
>
> Regards,
> Brian
>
> PS For those who might be wondering about artifacts like
> jini-core.jar, jini-ext.jar, sun-util.jar, etc., although there
> have been previous postings discussing how they are no
> longer needed, it might help some of the new folks on the
> list to hear a repeat of the history of those artifacts; and why
> they should not be used, and why they should probably be
> removed from the build.
>
> Back in the old jini 2.x release time frame, there was quite
> a bit of time and thought put into how the distribution should
> be re-packaged to address deployment issues; for example,
> better modularity, supporting overlays when upgrading, etc.
> That work resulted in the current artifact structure we now see;
> jsk-platform/jsk-lib/jsk-resources/jsk-dl/<service>/<service>-dl.
>
> But because the team did not want to break existing deployments
> that relied on the old jar structure, they decided to also include the
> old artifacts in the release; along with a detailed release note
> explaining the new philosophy and encouraging folks to move to
> the new model, and be prepared for the removal of those old jar
> files down the road. Unfortunately, due to unforeseen events, the
> removal of the old unnecessary jar files never occurred, and people
> seem to still be using them (at least, based on postings on the
> various user lists out there).
>
> With that in mind, one strategy regarding river and maven to
> consider might be that, rather than maven-izing the whole build
> process as the first step (which may be a huge undertaking),
> one might consider first placing the artifacts the current build
> process produces -- minus the unnecessary artifacts described
> above -- into a public maven repository; which is something that
> has been discussed in the past by Jeff Ramsdale and other
> maven experts on this list. This would then make it quite clear
> what jar files are necessary to use river. Additionally, although
> doing this as a first step is aimed at the users of river as opposed
> to river developers/contributors, it still may be a useful thing to
> do with respect to ease-of-use/deployment; and it may actually
> provide a bigger bang for the buck than one might expect.
>
> Anyway, it's just a thought.
Re: Closing out release 2.2.0
Posted by Brian Murphy <bt...@gmail.com>.
On Thu, Aug 26, 2010 at 8:31 AM, Peter Firmstone <ji...@zeus.net.au> wrote:
no one should need to depend on the *-dl.jar artefacts,
> he API that clients and services depend on are in the platform.jar The
> *-dl.jar artefacts are free to change there is no coupling,
Peter,
I'm not sure I understand what you mean above. Could you
explain what you mean regarding the *-dl.jar artifacts?
For what it's worth, from a maven (hopefully someday public)
repository point of view, the product my company is currently
working on depends on the following river artifacts:
browser.jar
classserver.jar
jsk-lib.jar
jsk-platform.jar
jsk-resources.jar
reggie.jar
start.jar
(and hopefully someday outrigger.jar and mahalo.jar)
browser-dl.jar
jsk-dl.jar
reggie-dl.jar
sdm-dl.jar
(and hopefully someday outrigger-dl.jar and mahalo-dl.jar)
Currently, we have placed the above artifacts in a
locally maintained maven repository that is updated
when new versions come out. We would like to someday
be able to pull these artifacts from a public repository
that would be automatically updated by the river
community. So, as you can see, we actually are
dependent on *-dl.jar files, and we're a bit concerned
by some of the discussion we've seen from time to
time regarding re-packaging the jar artifacts (although
since we're committed to river, I guess we'll just have
to adjust).
Anyway, with the above in mind, I think you can see
why your comment about no one depending on *-dl.jar
artifacts is a bit confusing.
Regards,
Brian
PS For those who might be wondering about artifacts like
jini-core.jar, jini-ext.jar, sun-util.jar, etc., although there
have been previous postings discussing how they are no
longer needed, it might help some of the new folks on the
list to hear a repeat of the history of those artifacts; and why
they should not be used, and why they should probably be
removed from the build.
Back in the old jini 2.x release time frame, there was quite
a bit of time and thought put into how the distribution should
be re-packaged to address deployment issues; for example,
better modularity, supporting overlays when upgrading, etc.
That work resulted in the current artifact structure we now see;
jsk-platform/jsk-lib/jsk-resources/jsk-dl/<service>/<service>-dl.
But because the team did not want to break existing deployments
that relied on the old jar structure, they decided to also include the
old artifacts in the release; along with a detailed release note
explaining the new philosophy and encouraging folks to move to
the new model, and be prepared for the removal of those old jar
files down the road. Unfortunately, due to unforeseen events, the
removal of the old unnecessary jar files never occurred, and people
seem to still be using them (at least, based on postings on the
various user lists out there).
With that in mind, one strategy regarding river and maven to
consider might be that, rather than maven-izing the whole build
process as the first step (which may be a huge undertaking),
one might consider first placing the artifacts the current build
process produces -- minus the unnecessary artifacts described
above -- into a public maven repository; which is something that
has been discussed in the past by Jeff Ramsdale and other
maven experts on this list. This would then make it quite clear
what jar files are necessary to use river. Additionally, although
doing this as a first step is aimed at the users of river as opposed
to river developers/contributors, it still may be a useful thing to
do with respect to ease-of-use/deployment; and it may actually
provide a bigger bang for the buck than one might expect.
Anyway, it's just a thought.
Re: Closing out release 2.2.0
Posted by Jonathan Costers <jo...@googlemail.com>.
>
>
>
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.
>
>
I'm sorry Peter.
What I meant was closing out the release that you put together in March, so
2.1.2, not 2.2.0 ...
There are some small things left to do (see my original message).
So everywhere I mentioned 2.2.0, I actually mean 2.1.2 ... Sorry for causing
confusion.
I am not at all trying to steer towards a new release or anything :-)
2010/8/26 Peter Firmstone <ji...@zeus.net.au>
>
> See also:
>> https://issues.apache.org/jira/browse/RIVER-317
>> https://issues.apache.org/jira/browse/RIVER-300
>>
>>
>> 2010/8/26 Benson Margulies <bi...@gmail.com>
>>
>>
>>
>>> 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 <pa...@acm.org> 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
>>>>
>>>>
>>>>
>>>
>>
>>
>
>
Re: Closing out release 2.2.0
Posted by Peter Firmstone <ji...@zeus.net.au>.
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 <bi...@gmail.com>
>
>
>> 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 <pa...@acm.org> 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
>>>
>>>
>
>
Re: Closing out release 2.2.0
Posted by Jonathan Costers <jo...@googlemail.com>.
One thing we could do more or less now is publish the River artifacts into a
Maven repository somewhere.
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.
See also:
https://issues.apache.org/jira/browse/RIVER-317
https://issues.apache.org/jira/browse/RIVER-300
2010/8/26 Benson Margulies <bi...@gmail.com>
> 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 <pa...@acm.org> 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
> >
>
Re: Closing out release 2.2.0
Posted by Benson Margulies <bi...@gmail.com>.
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 <pa...@acm.org> 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
>
Re: Closing out release 2.2.0
Posted by Patricia Shanahan <pa...@acm.org>.
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
Re: Closing out release 2.2.0
Posted by Sim IJskes - QCG <si...@qcg.nl>.
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.
Gr. Sim
Re: Closing out release 2.2.0
Posted by Patrick Wright <pd...@gmail.com>.
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.
Patrick
On Thu, Aug 26, 2010 at 10:31 AM, Sim IJskes - QCG <si...@qcg.nl> wrote:
> On 08/26/2010 03:13 AM, Benson Margulies wrote:
>>
>> Here we have a minor dilemma. I might count as a qualified person, but
>> I'm a bit swamped and there is some feeling that mentoring and
>> developering should be distinct. Maybe I'll have a look and see what I
>> see.
>
> I'm not directly in favor of a maven build procedure. I don't have a problem
> with ant based build scripts. I love them!
>
> I dont mind an experiment in a skunk branch, where we prove we can create
> repeatable builds, complete build results for src/doc/bin, usable without
> maven and show that this repeatability is easily maintained (i mean on the
> human/procedure side).
Re: Closing out release 2.2.0
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 08/26/2010 03:13 AM, Benson Margulies wrote:
> Here we have a minor dilemma. I might count as a qualified person, but
> I'm a bit swamped and there is some feeling that mentoring and
> developering should be distinct. Maybe I'll have a look and see what I
> see.
I'm not directly in favor of a maven build procedure. I don't have a
problem with ant based build scripts. I love them!
I dont mind an experiment in a skunk branch, where we prove we can
create repeatable builds, complete build results for src/doc/bin, usable
without maven and show that this repeatability is easily maintained (i
mean on the human/procedure side).
Gr. Sim
Re: Closing out release 2.2.0
Posted by Benson Margulies <bi...@gmail.com>.
Here we have a minor dilemma. I might count as a qualified person, but
I'm a bit swamped and there is some feeling that mentoring and
developering should be distinct. Maybe I'll have a look and see what I
see.
On Wed, Aug 25, 2010 at 8:48 PM, Patricia Shanahan <pa...@acm.org> wrote:
> Is there any chance that we could borrow an Ant-to-Maven expert to do the
> conversion, either now or at some later time? Presumably, there are people
> working on other projects who have already done this a time or two.
>
> The River build looks too complicated to me to be a good choice for anyone's
> first Maven project, but maintaining the Maven build once it is working
> would presumably be significantly easier. The Ant-to-Maven expert would not
> need to make a long term commitment to River.
>
> Patricia
>
>
> On 8/25/2010 5:10 PM, Jonathan Costers wrote:
>>
>> I think the main issue is that none of us are experts in Maven.
>> The River project is quite complex and wouldn't directly fit into the
>> standard Maven paradigms.
>>
>> some examples:
>> - packaging our artificacts (using classdep)
>> - dependency management (using Class-Path in manifests, -dl dependencies)
>> - running our test suites from a Maven build
>>
>> I think it would certainly be possible to overcome these hurdles, and if I
>> had more time to spend I would certainly take a closer look.
>> Up until now however, since we have a basic build working (with Ant,
>> unfortunately) and have the contributed test harness integrated in that,
>> focus has been on increasing test coverage by enabling more tests.
>>
>> Enabling these contributed tests is important because they were previously
>> used by Sun for QA and regression testing their Jini distributions.
>> Every day we can't run all of these tests is a risk that bugs are
>> (re)introduced without notice (in fact, it already happened).
>>
>> 2010/8/26 Benson Margulies<bi...@gmail.com>
>>
>>> I haven't looked at the River build. Does it have a lot of intricate
>>> antification that's hard to map?
>>>
>>> On Wed, Aug 25, 2010 at 7:34 PM, Jonathan Costers
>>> <jo...@googlemail.com> wrote:
>>>>
>>>> very true ... if we would be able to switch to a Maven build, many
>>>
>>> headaches
>>>>
>>>> would be avoided.
>>>>
>>>> the switching itself is not as easy as it may seem though ...
>>>>
>>>> 2010/8/26 Benson Margulies<bi...@gmail.com>
>>>>
>>>>> Well, you could switch to a maven build and let the release plugin
>>>>> worry about this.
>>>>>
>>>>> *** humorous intrusion ***
>>>>>
>>>>> On Wed, Aug 25, 2010 at 7:06 PM, Jonathan Costers
>>>>> <jo...@googlemail.com> wrote:
>>>>>>
>>>>>> Some minor things are left to be done:
>>>>>> - release AR2 in JIRA and give it the name "2.2.0".
>>>>>> - change the version property in common.xml to "2.2.0" in the AR2
>>>
>>> branch,
>>>>>>
>>>>>> rebuild the AR2 branch and publish the artifacts as the official 2.2.0
>>>>>> release.
>>>>>> - change the version property in common.xml to the next target version
>>>
>>> in
>>>>>>
>>>>>> trunk and highlight it is under development (2.2.1-SNAPSHOT?)
>>>>>>
>>>>>> Thoughts?
>>>>>> Jonathan
>>>>>>
>>>>>
>>>>
>>>
>>
>
>
Re: Closing out release 2.2.0
Posted by Patricia Shanahan <pa...@acm.org>.
Is there any chance that we could borrow an Ant-to-Maven expert to do
the conversion, either now or at some later time? Presumably, there are
people working on other projects who have already done this a time or two.
The River build looks too complicated to me to be a good choice for
anyone's first Maven project, but maintaining the Maven build once it is
working would presumably be significantly easier. The Ant-to-Maven
expert would not need to make a long term commitment to River.
Patricia
On 8/25/2010 5:10 PM, Jonathan Costers wrote:
> I think the main issue is that none of us are experts in Maven.
> The River project is quite complex and wouldn't directly fit into the
> standard Maven paradigms.
>
> some examples:
> - packaging our artificacts (using classdep)
> - dependency management (using Class-Path in manifests, -dl dependencies)
> - running our test suites from a Maven build
>
> I think it would certainly be possible to overcome these hurdles, and if I
> had more time to spend I would certainly take a closer look.
> Up until now however, since we have a basic build working (with Ant,
> unfortunately) and have the contributed test harness integrated in that,
> focus has been on increasing test coverage by enabling more tests.
>
> Enabling these contributed tests is important because they were previously
> used by Sun for QA and regression testing their Jini distributions.
> Every day we can't run all of these tests is a risk that bugs are
> (re)introduced without notice (in fact, it already happened).
>
> 2010/8/26 Benson Margulies<bi...@gmail.com>
>
>> I haven't looked at the River build. Does it have a lot of intricate
>> antification that's hard to map?
>>
>> On Wed, Aug 25, 2010 at 7:34 PM, Jonathan Costers
>> <jo...@googlemail.com> wrote:
>>> very true ... if we would be able to switch to a Maven build, many
>> headaches
>>> would be avoided.
>>>
>>> the switching itself is not as easy as it may seem though ...
>>>
>>> 2010/8/26 Benson Margulies<bi...@gmail.com>
>>>
>>>> Well, you could switch to a maven build and let the release plugin
>>>> worry about this.
>>>>
>>>> *** humorous intrusion ***
>>>>
>>>> On Wed, Aug 25, 2010 at 7:06 PM, Jonathan Costers
>>>> <jo...@googlemail.com> wrote:
>>>>> Some minor things are left to be done:
>>>>> - release AR2 in JIRA and give it the name "2.2.0".
>>>>> - change the version property in common.xml to "2.2.0" in the AR2
>> branch,
>>>>> rebuild the AR2 branch and publish the artifacts as the official 2.2.0
>>>>> release.
>>>>> - change the version property in common.xml to the next target version
>> in
>>>>> trunk and highlight it is under development (2.2.1-SNAPSHOT?)
>>>>>
>>>>> Thoughts?
>>>>> Jonathan
>>>>>
>>>>
>>>
>>
>
Re: Closing out release 2.2.0
Posted by Jonathan Costers <jo...@googlemail.com>.
I think the main issue is that none of us are experts in Maven.
The River project is quite complex and wouldn't directly fit into the
standard Maven paradigms.
some examples:
- packaging our artificacts (using classdep)
- dependency management (using Class-Path in manifests, -dl dependencies)
- running our test suites from a Maven build
I think it would certainly be possible to overcome these hurdles, and if I
had more time to spend I would certainly take a closer look.
Up until now however, since we have a basic build working (with Ant,
unfortunately) and have the contributed test harness integrated in that,
focus has been on increasing test coverage by enabling more tests.
Enabling these contributed tests is important because they were previously
used by Sun for QA and regression testing their Jini distributions.
Every day we can't run all of these tests is a risk that bugs are
(re)introduced without notice (in fact, it already happened).
2010/8/26 Benson Margulies <bi...@gmail.com>
> I haven't looked at the River build. Does it have a lot of intricate
> antification that's hard to map?
>
> On Wed, Aug 25, 2010 at 7:34 PM, Jonathan Costers
> <jo...@googlemail.com> wrote:
> > very true ... if we would be able to switch to a Maven build, many
> headaches
> > would be avoided.
> >
> > the switching itself is not as easy as it may seem though ...
> >
> > 2010/8/26 Benson Margulies <bi...@gmail.com>
> >
> >> Well, you could switch to a maven build and let the release plugin
> >> worry about this.
> >>
> >> *** humorous intrusion ***
> >>
> >> On Wed, Aug 25, 2010 at 7:06 PM, Jonathan Costers
> >> <jo...@googlemail.com> wrote:
> >> > Some minor things are left to be done:
> >> > - release AR2 in JIRA and give it the name "2.2.0".
> >> > - change the version property in common.xml to "2.2.0" in the AR2
> branch,
> >> > rebuild the AR2 branch and publish the artifacts as the official 2.2.0
> >> > release.
> >> > - change the version property in common.xml to the next target version
> in
> >> > trunk and highlight it is under development (2.2.1-SNAPSHOT?)
> >> >
> >> > Thoughts?
> >> > Jonathan
> >> >
> >>
> >
>
Re: Closing out release 2.2.0
Posted by Benson Margulies <bi...@gmail.com>.
I haven't looked at the River build. Does it have a lot of intricate
antification that's hard to map?
On Wed, Aug 25, 2010 at 7:34 PM, Jonathan Costers
<jo...@googlemail.com> wrote:
> very true ... if we would be able to switch to a Maven build, many headaches
> would be avoided.
>
> the switching itself is not as easy as it may seem though ...
>
> 2010/8/26 Benson Margulies <bi...@gmail.com>
>
>> Well, you could switch to a maven build and let the release plugin
>> worry about this.
>>
>> *** humorous intrusion ***
>>
>> On Wed, Aug 25, 2010 at 7:06 PM, Jonathan Costers
>> <jo...@googlemail.com> wrote:
>> > Some minor things are left to be done:
>> > - release AR2 in JIRA and give it the name "2.2.0".
>> > - change the version property in common.xml to "2.2.0" in the AR2 branch,
>> > rebuild the AR2 branch and publish the artifacts as the official 2.2.0
>> > release.
>> > - change the version property in common.xml to the next target version in
>> > trunk and highlight it is under development (2.2.1-SNAPSHOT?)
>> >
>> > Thoughts?
>> > Jonathan
>> >
>>
>
Re: Closing out release 2.2.0
Posted by Jonathan Costers <jo...@googlemail.com>.
very true ... if we would be able to switch to a Maven build, many headaches
would be avoided.
the switching itself is not as easy as it may seem though ...
2010/8/26 Benson Margulies <bi...@gmail.com>
> Well, you could switch to a maven build and let the release plugin
> worry about this.
>
> *** humorous intrusion ***
>
> On Wed, Aug 25, 2010 at 7:06 PM, Jonathan Costers
> <jo...@googlemail.com> wrote:
> > Some minor things are left to be done:
> > - release AR2 in JIRA and give it the name "2.2.0".
> > - change the version property in common.xml to "2.2.0" in the AR2 branch,
> > rebuild the AR2 branch and publish the artifacts as the official 2.2.0
> > release.
> > - change the version property in common.xml to the next target version in
> > trunk and highlight it is under development (2.2.1-SNAPSHOT?)
> >
> > Thoughts?
> > Jonathan
> >
>
Re: Closing out release 2.2.0
Posted by Benson Margulies <bi...@gmail.com>.
Well, you could switch to a maven build and let the release plugin
worry about this.
*** humorous intrusion ***
On Wed, Aug 25, 2010 at 7:06 PM, Jonathan Costers
<jo...@googlemail.com> wrote:
> Some minor things are left to be done:
> - release AR2 in JIRA and give it the name "2.2.0".
> - change the version property in common.xml to "2.2.0" in the AR2 branch,
> rebuild the AR2 branch and publish the artifacts as the official 2.2.0
> release.
> - change the version property in common.xml to the next target version in
> trunk and highlight it is under development (2.2.1-SNAPSHOT?)
>
> Thoughts?
> Jonathan
>