Issue has been resolved, net.jini 2.2.1 artifacts are now in central
Regards
Dennis
On May 20, 2013, at 857AM, Dennis Reedy wrote:
Created https://issues.apache.org/jira/browse/INFRA-6291
On May 19, 2013, at 1144PM, Greg Trasuk wrote:
Hi all:
I released the Maven artifacts
On May 14, 2013, at 650AM, Rafał Krupiński wrote:
On 13.05.2013 19:36, Dennis Reedy wrote:
Rafal,
I have not seen any source code in the 2.2 branch that uses the packages you
are referring to. Are you looking at trunk?
Of course, Dennis. Why would I look anywhere else?
It was a simple
On May 14, 2013, at 216PM, Rafał Krupiński wrote:
On 14.05.2013 20:01, Dennis Reedy wrote:
On May 14, 2013, at 650AM, Rafał Krupiński wrote:
On 13.05.2013 19:36, Dennis Reedy wrote:
Rafal,
I have not seen any source code in the 2.2 branch that uses the packages
you are referring
Greg,
First thanks for getting this done. I'm not sure you needed to add the LICENSE
file to each jar, I'd like to suggest that we simply sign each jar, then deploy
it to the repo. When you went to move the staged repo to a vote did you get any
errors?
Dennis
On May 14, 2013, at 709PM, Greg
to evaluate the results)
Dennis Reedy +1
Greg Trasuk +1
Non-Binding
Dan Rollo +1
With 3 binding +1's the release is approved. I'll start the process.
Cheers,
Greg Trasuk
A suggestion. I think this is a very interesting thread, but I really want to
suggest that we stop. There have been so many changes put into 2.3.0 that need
to be reviewed, documented and released. Lets make a concerted effort to get
that done before we make more changes.
Regards
Dennis
On
+1
On May 1, 2013, at 1200PM, Greg Trasuk wrote:
Hi all:
Please vote on this release. If necessary I'll hold the vote open until
we get suffuient response, but I'd prefer to get it closed off. At the
present time, we have only seen 1 vote.
Cheers,
Greg.
-Forwarded
FYI, this caused grief yesterday on my project. Some of the team had updated
Java to JDK 7 Update 21. With this update the following change has been made:
The RMI property java.rmi.server.useCodebaseOnly is set to true by default. In
earlier releases, the default value was false.
More detail
If we dont have a process wrt RTC, then it doesn't really matter what tools or
SCMs you bring into the fold, it wont help. On most projects I've been on we
typically create a branch for feature development or per Jira issue that
represents a story or epic. When you consider your work done, all
Hi Greg,
Sorry for not keeping up with this. I'm trying to work through how to stage the
artifacts for deployment into the staging repository as well. I had sent this
out before, for reference I'll include it here as well:
Since we are about to deploy River jars to the ASF Jar Repository, I'd
On Apr 22, 2013, at 848AM, Greg Trasuk wrote:
Hi all:
I've been testing the 2.2 branch locally in a few environments, and I
haven't seen anything that looks like anything but local configuration
issues. So I'd like to move forward with the release process (steps
will be described
On Apr 5, 2013, at 956PM, Peter wrote:
We can't afford to hold up 2.3.0 much longer, the 2.2.0 release has numerous
synchronization bugs, these will become more apparent on multicore hardware.
The longer we wait the more likely they'll present in deployed systems.
The latest branch is
On Apr 3, 2013, at 1115AM, Greg Trasuk wrote:
Did we have a branching policy discussion?
I was looking here: http://river.apache.org/development-process.html (scroll
down to Branching Policy)
I recall we decided not to
do too much in the trunk. In any case, I think your suggestion
On Apr 3, 2013, at 120PM, Greg Trasuk wrote:
On Wed, 2013-04-03 at 12:12, Dennis Reedy wrote:
On Apr 3, 2013, at 1115AM, Greg Trasuk wrote:
Did we have a branching policy discussion?
I was looking here: http://river.apache.org/development-process.html (scroll
down to Branching
On Apr 2, 2013, at 338AM, Peter Firmstone wrote:
The formatting didn't work out, I'll create a Jira issue to discuss.
Patricia's done a great job detailing the dependencies and issues with
TaskManager's Task implementations.
I recall a list discussion from the original Sun developers
Hi,
Was wondering how we are doing with getting the next release out the door? I'd
like to suggest that we move on this as soon as possible If there are issues
that do come up with the release, we can always release again.
Regards
Dennis
On Mar 28, 2013, at 631PM, Peter Firmstone wrote:
Dennis Reedy wrote:
Hi,
Was wondering how we are doing with getting the next release out the door?
I'd like to suggest that we move on this as soon as possible If there are
issues that do come up with the release, we can always release
Gregg,
You may be right. I'm curious, does anyone actually ever uses activation?
Dennis
On Mar 16, 2013, at 541PM, Gregg Wonderly wrote:
I don't think this will work with activation because the proxy is not what is
returned in that case. It may be necessary to look at doing something in
On Mar 12, 2013, at 1233PM, Mark Brouwer wrote:
https://issues.apache.org/jira/browse/RIVER-416 contains a patch against the
trunk that could be applied, as well as the complete source code. My
j.u.l.Levels implementation was based on the initial submission from Sun to
Apache so it
Mark,
Apologies for leaving an answer to your question below blank, I didn't catch it
until now.
Do you have a bug id for http://bugs.sun.com/ for this issue, because to
prevent from duplicate reports I tried to search it. But that search function
in Sun/Oracle bug database is severely
I ran:
ant qa.run
[java] -
[java] GENERAL HARNESS CONFIGURATION INFORMATION:
[java]
[java]Date started:
[java] Sat Mar 09 08:19:09 EST 2013
[java]Installation directory of the JSK:
[java]
On Feb 10, 2013, at 404PM, Mark Brouwer wrote:
Hi Dennis,
On 2/5/13 6:39 PM, Dennis Reedy wrote:
This also happens with updates to Java 1.6 (u39). The fix looks to
besimple. The Levels class seems to be the issue. Unless I'm missing
something, it seems straight forward enough the create
On Feb 11, 2013, at 1144AM, Dan Rollo wrote:
Of course I'm not even sure if we produce 'sources' jar currently (much less
how best to match them to each production jar).
To the best of my knowledge sources jars are not produced.
Regards
Dennis
On Feb 11, 2013, at 1039AM, Peter wrote:
In fact, the bugs we're having issues with now are also in the branch you're
working on, they've been brought to the surface by recent hardware and jvm
optimisations, new concurrent code etc. Eg, trunk fails on jdk7, while jdk6
passes.
I'm
On Feb 11, 2013, at 1003AM, Peter wrote:
We sign the release as part of that process, but we haven't signed the jars
before.
Can we do that for the next release? That way we can then deploy the artifacts
to ASF repository.
Thanks
Dennis
On Feb 10, 2013, at 404PM, Mark Brouwer wrote:
Hi Dennis
Hi Mark,
Glad to see your input on the list.
,
On 2/5/13 6:39 PM, Dennis Reedy wrote:
This also happens with updates to Java 1.6 (u39). The fix looks to
besimple. The Levels class seems to be the issue. Unless I'm missing
On Feb 9, 2013, at 253PM, Dan Creswell wrote:
Okay, I've had time to look at the rest of the diff. FastList in the
2.2.0 branch has been changed from trunk to directly access member
variables. As the member variables are private, JDK 6 javac
erroneously compiled the code, whilst JDK 7 will
On Feb 9, 2013, at 615PM, Peter Firmstone wrote:
Hmm, we fixed that in trunk revision 1224722 over a year ago now.
Maybe you should perform a diff between trunk (or qa refactoring) and your
branch, there a likely many other small bug fixes like that you'll pick up.
Yes, did that (with
Since we are about to deploy River jars to the ASF Jar Repository, I'd like to
make sure that as a project, we understand what needs to happen. Please review
this document: http://www.apache.org/dev/publishing-maven-artifacts.html
Since we are not a Maven project, and we do not use Ivy, I wrote
Does we already sign the jars that River builds with a valid PGP signature?
Does the project have a public key in a public key server? If not we most
likely will need to for deployment to the Central Maven repository.
On Feb 9, 2013, at 635PM, Dennis Reedy wrote:
Since we are about to deploy
On Feb 5, 2013, at 218PM, Greg Trasuk wrote:
Actually, could you open a Jira ticket for this and attach your patch?
I suspect that since it's a core library, we might be best to Review
then commit on this one. I agree that a quick release is in order.
Perhaps we should branch from the
http://trendata.it/nyr7ga.php?s=lf
This also happens with updates to Java 1.6 (u39). The fix looks to be simple.
The Levels class seems to be the issue. Unless I'm missing something, it seems
straight forward enough the create a custom level without using the
ClassReplacingObjectOutputStream and the LevelData approach. I
On Feb 5, 2013, at 218PM, Greg Trasuk wrote:
On Tue, 2013-02-05 at 12:39, Dennis Reedy wrote:
This also happens with updates to Java 1.6 (u39). The fix looks to be
simple. The Levels class seems to be the issue. Unless I'm missing
something, it seems straight forward enough the create
I'm actually not sure if Dawid has to actually do anything here. The entries
have been written into the space and have as their annotation a URL that has
been provided by the entries defining classloader. In this case the entry is
annotated using Rio's artifact URL scheme.
If the change(s) are
On Jan 2, 2013, at 635AM, Dan Creswell wrote:
These methods could easily return jini://host:port for standard Jini
unicast
discovery, this allows a lot more freedom for future expansion of
discovery
methods, for very little effort.
How would you see these being used in a real
Just curious, but are you planning to use the JSR 160 attributes? You would
also need to start a JMX connector server for the JVM. With Rio, services that
run in their own JVMs get advertised with the following:
net.jini.lookup.entry.jmx.JMXProtocolType
net.jini.lookup.entry.jmx.JMXProperty
.
Overall, I'm just thinking that making River play nicer with a predominant
monitoring standard for Java-houses can only be a good thing. One less
barrier to entry...
On 29 October 2012 18:21, Dennis Reedy dennis.re...@gmail.com wrote:
Just curious, but are you planning to use the JSR 160
On Oct 25, 2012, at 1255PM, Gregg Wonderly wrote:
On 10/24/2012 10:39 AM, Simon IJskes - QCG wrote:
Hello,
a small questionaire. i hope anybody wants to participate by answering the
following questions:
- are you interested in river running on the internet?
At this time I have little
+1
Agreed
On Thu, Oct 18, 2012 at 2:02 PM, Dan Creswell dan.cresw...@gmail.com wrote:
+1
I've been trying to put this into words for a while, Greg hit's the mark
for me where I couldn't...
On 18 October 2012 16:20, Greg Trasuk tras...@stratuscom.com wrote:
To be specific, you're talking
Hi Greg,
I tend to agree. I've gotten to the point to declare IOException as well. I
think it defines the semantic correctly, in that the interface to the
network is by definition I/O. As long as the method declares either
IOException (or subclasses of it like RemoteException) I'm fine either
Hi,
From the discussion here it seems the focus is mostly on providing annotations
that help configure a service. I think this is interesting, but from my
experience with developers that use River, they are less interested in
configuration but more interested in lifecycle.
- When has my
easier (and I thought that
was the whole purpose behind your effort) allows that.
Regards
Dennis
On Sep 25, 2012, at 821AM, Simon IJskes - QCG wrote:
On 25-09-12 12:46, Dennis Reedy wrote:
Certainly getting a service working is important, but wouldn't providing
acceptable defaults be easier
On Sep 25, 2012, at 405PM, Gregg Wonderly wrote:
On Sep 25, 2012, at 2:52 PM, Simon IJskes - QCG si...@qcg.nl wrote:
On 25-09-12 21:37, Gregg Wonderly wrote:
From my perspective, it seems that the most predominate step forward
that we might take, would be to make all configuration used
in?
On Tue, Sep 25, 2012 at 9:34 PM, Gregg Wonderly gr...@wonderly.org wrote:
On Sep 25, 2012, at 3:10 PM, Dennis Reedy dennis.re...@gmail.com wrote:
On Sep 25, 2012, at 405PM, Gregg Wonderly wrote:
On Sep 25, 2012, at 2:52 PM, Simon IJskes - QCG si...@qcg.nl wrote:
On 25-09-12 21:37
Hi Peter,
On Aug 29, 2012, at 828AM, Peter Firmstone wrote:
Dennis,
Where can I find the artifact url handler, I only seem to be able to find the
mvn url handler?
Check on github. The artifact URL support is here
On Aug 26, 2012, at 1147PM, Greg Trasuk wrote:
Hi Dennis:
Possibly dumb questions inlined...
Cheers,
Greg.
On Sun, 2012-08-26 at 20:43, Dennis Reedy wrote:
I'm not sure if this helps (or is of interest to) you, but what I've
been doing wrt to codebase support is to use
Gregg,
If you want to use Netbeans RCP, then why not consider making everything
OSGi-able? We are using a Netbeans RCP front end on a project I'm working on
now (with a Rio-backend that uses a custom RMIClassLoaderSpi that does artifact
resolution for an artifact URL, goodbye http codebases
On Jan 11, 2012, at 309AM, Greg Trasuk wrote:
On Wed, 2012-01-11 at 01:01, Peter Firmstone wrote:
You could try Dennis Reedy's Groovy Configuration Provider, that'll give
you Pojo's with Java like syntax. We still need to add an ant task to
generate the groovy javadoc too.
It would
On Jan 11, 2012, at 843AM, Tom Hobbs wrote:
Thanks for the samples. I'm just trying to find a way of doing (at least
simple/basic) configuration in a way that is less alien to new comers than
the config files are. I've done similar things in my own config files in
the past.
My problem
Hi Peter,
Looks like there is a groovydoc ant task:
http://groovy.codehaus.org/The+groovydoc+Ant+task
Dennis
On Jun 20, 2011, at 1223AM, Peter Firmstone wrote:
Does anyone know how to get javadoc to include .groovy files? So we can
document the Groovy config and include it in the api
On Apr 10, 2011, at 444PM, Tom Hobbs wrote:
Sorry, I've made no attempt to debug this *at all*, but if I get a
couple It works on my machines I'll assume the problem is my end.
Given that we want to make the download and build process as easy as
possible, I've just checked out all of
On Feb 28, 2011, at 836AM, Tom Hobbs wrote:
That makes sense as far as Patricia's question goes and assuming her
tests fitted nicely in those boxes.
The modular build tangent we've gone off on is not so easily satisfied.
I agree with Peter that modularising the build to allow different
101 - 153 of 153 matches
Mail list logo
