You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Steve Vinoski <vi...@iona.com> on 2006/11/15 17:29:11 UTC
Re: svn commit: r475297 - /incubator/qpid/trunk/qpid/java/broker/src/org/apache/qpid/server/Main.java
I've seen several mina-related commits go by today related to bring
code up to mina-HEAD, but I must admit I still don't understand the
desire to be using code straight from mina that isn't available in a
maven repository yet.
The reason? Well, yesterday I thought we all agreed to mavenize the
trunk after M1. These commits prevent that. We can't even be picking
up mina snapshots, because we can't release M2 or another release
with snapshot dependencies, unless of course those snapshots turn
into real releases before M2.
The mvn branch works with released mina 1.0.0. To the best of my
knowledge, 1.0.0 is the latest official release of mina. I've stated
that several times, but it just seems to be glossed over and ignored.
What critical bugs are fixed by picking up mina-HEAD? Are they truly
critical showstoppers that absolutely have to be in trunk today?
--steve
On my b
On Nov 15, 2006, at 11:21 AM, ritchiem@apache.org wrote:
> Author: ritchiem
> Date: Wed Nov 15 08:21:02 2006
> New Revision: 475297
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=475297
> Log:
> Removed local development code that made it into the repository
>
> Modified:
> incubator/qpid/trunk/qpid/java/broker/src/org/apache/qpid/
> server/Main.java
>
> Modified: incubator/qpid/trunk/qpid/java/broker/src/org/apache/qpid/
> server/Main.java
> URL: http://svn.apache.org/viewvc/incubator/qpid/trunk/qpid/java/
> broker/src/org/apache/qpid/server/Main.java?
> view=diff&rev=475297&r1=475296&r2=475297
> ======================================================================
> ========
> --- incubator/qpid/trunk/qpid/java/broker/src/org/apache/qpid/
> server/Main.java (original)
> +++ incubator/qpid/trunk/qpid/java/broker/src/org/apache/qpid/
> server/Main.java Wed Nov 15 08:21:02 2006
> @@ -320,19 +320,7 @@
>
> SocketSessionConfig sc;
>
> - //fixme improve get to use configuration
> - if (connectorConfig.qpidNIO)
> - {
> - //FIXME - this needs to be sorted to use the new
> Mina MultiThread SA.
> - _logger.warn("Using Qpid NIO - DISABLED");
> - //sconfig =
> (org.apache.mina.transport.socket.nio.MultiThreadSocketAcceptorConfig)
> acceptor.getDefaultConfig();
> - //sc = (SocketSessionConfig)
> sconfig.getSessionConfig();
> - }
> -// else
> - {
> - _logger.warn("Using Mina NIO");
> - sc = (SocketSessionConfig)
> acceptor.getSessionConfig();
> - }
> + sc = (SocketSessionConfig) acceptor.getSessionConfig();
>
> sc.setReceiveBufferSize
> (connectorConfig.socketReceiveBufferSize);
> sc.setSendBufferSize
> (connectorConfig.socketWriteBuferSize);
>
>
Re: svn commit: r475297 - /incubator/qpid/trunk/qpid/java/broker/src/org/apache/qpid/server/Main.java
Posted by Steve Vinoski <vi...@iona.com>.
On Nov 15, 2006, at 2:34 PM, Marnie McCormack wrote:
> IIRC when Steve initially proposed introducing maven to the project
> we had
> some debate, but it seems like there might be limitations/constraints
> imposed that we didn't understand (as a group).
As the other email thread on maven has already mentioned, these
limitations exist regardless of maven, I believe. Maven simply
enforces them.
> I can also see, from Daniel's posts, that other projects who use
> maven would
> like us to follow suit as it'll make their lives easier.
Very much so.
> So, there are pros & cons. What I think would be very helpful
> though (as
> others have indicated) is a list of the things we can't do with
> maven (that
> might impact us) ? We can then agree a way round/accept the
> limitation/other
> as appropriate.
>
> I know there have been a few items discussed in previous threads,
> and I'm
> not very clear on where these things are at e.g. resolved, tricky but
> fixable or really not possible.
>
> So, for example, javadoc inclusion, mina snapshot, etc.
Javadoc is not an issue for maven, i.e., it can easily be done. I
didn't include it yet because I question its value as we currently
implement it. Simply javadoc'ing every class is pointless. What needs
to be javadoc'ed are the classes that users actually use. Tuscany,
CXF, and Yoko do this by building an API jar, which they then javadoc.
The mina snapshot is an issue, as the other email thread is currently
exploring. There is no mina 1.1.0-SNAPSHOT available in the maven
repositories anymore, but I don't know the reason for that. Only the
mina team does. But as I've said, 1.0.0 works for us, and that's the
dependency the mvn branch poms specify.
None of the issues Martin raised are a big deal at all with respect
to maven. I was prepared to fix them all yesterday, in fact.
> One way to do make where we are with maven clear would be to raise
> JIRAs for
> the outstanding items. That way we can all see where we are, and
> discuss
> anything truly significant.
Can do, but I don't think it makes sense to do that unless it's on
trunk.
> It may be that you've already been able to resolve the items on
> Martin's
> list Steve ? No time pressure from my perspective, just a sense
> that we're
> perhaps a bit muddy at the moment.
Well, yesterday I spent most of the day arguing in email. Once I saw
the writing on the wall regarding maven and M1, I backed off
aggressively working on it so I could catch up on other stuff.
> Also Steve - if you could still do with a hand, JIRAs would be a
> good way to
> get others involved now that M1 is pretty much done ?
Yep, as soon as maven is on trunk. I guess I should just merge it.
--steve
>
> Regards,
> Marnie
>
>
>
>
> On 11/15/06, Martin Ritchie <ri...@apache.org> wrote:
>>
>> I really hope that we don't have to rely on publicly available
>> releases. What if a bug in one of our dependencies prevents us
>> releasing because we have to wait for them despite there being a well
>> used patch available? Do other OS projects just wait for their
>> dependent projects to release? Does this approach foster a greater
>> community as you have to help out projects you are dependent on?
>> Fixing problems and release so that you can focus on your own
>> projects.
>>
>> Such a limitation of maven which would have been good to know up
>> front
>> before we embarked on maven-ization. I'm really struggling to see
>> what
>> maven brings to the table.
>>
>> On 15/11/06, Steven Shaw <st...@gmail.com> wrote:
>> > I'm sure you can do some kind of artifact:install in order to
>> put jars
>> > into your local repository (from your workspace). We could do that
>> > with MINA and perhaps filecontext.
>> >
>> > See the following link under "Installing and Deploying Your Own
>> Artifacts":
>> >
>> > http://maven.apache.org/ant-tasks.html
>> >
>> > The Maven experts will need to verify though!
>> >
>> > Steve.
>> >
>>
>>
>> --
>> Martin Ritchie
>>
Re: Re: svn commit: r475297 - /incubator/qpid/trunk/qpid/java/broker/src/org/apache/qpid/server/Main.java
Posted by Rajith Attapattu <ra...@gmail.com>.
Hi Folks,
>From what I know the incubator PMC may not approve releases that depends on
SNAPSHOTS.
I maybe wrong, but it's better to find this out.
Cliff, can you please confirm?
Regards,
Rajith
On 11/15/06, Marnie McCormack <ma...@googlemail.com> wrote:
>
> IIRC when Steve initially proposed introducing maven to the project we had
> some debate, but it seems like there might be limitations/constraints
> imposed that we didn't understand (as a group).
>
> I can also see, from Daniel's posts, that other projects who use maven
> would
> like us to follow suit as it'll make their lives easier.
>
> So, there are pros & cons. What I think would be very helpful though (as
> others have indicated) is a list of the things we can't do with maven
> (that
> might impact us) ? We can then agree a way round/accept the
> limitation/other
> as appropriate.
>
> I know there have been a few items discussed in previous threads, and I'm
> not very clear on where these things are at e.g. resolved, tricky but
> fixable or really not possible.
>
> So, for example, javadoc inclusion, mina snapshot, etc.
>
> One way to do make where we are with maven clear would be to raise JIRAs
> for
> the outstanding items. That way we can all see where we are, and discuss
> anything truly significant.
>
> It may be that you've already been able to resolve the items on Martin's
> list Steve ? No time pressure from my perspective, just a sense that we're
> perhaps a bit muddy at the moment.
>
> Also Steve - if you could still do with a hand, JIRAs would be a good way
> to
> get others involved now that M1 is pretty much done ?
>
> Regards,
> Marnie
>
>
>
>
> On 11/15/06, Martin Ritchie <ri...@apache.org> wrote:
> >
> > I really hope that we don't have to rely on publicly available
> > releases. What if a bug in one of our dependencies prevents us
> > releasing because we have to wait for them despite there being a well
> > used patch available? Do other OS projects just wait for their
> > dependent projects to release? Does this approach foster a greater
> > community as you have to help out projects you are dependent on?
> > Fixing problems and release so that you can focus on your own
> > projects.
> >
> > Such a limitation of maven which would have been good to know up front
> > before we embarked on maven-ization. I'm really struggling to see what
> > maven brings to the table.
> >
> > On 15/11/06, Steven Shaw <st...@gmail.com> wrote:
> > > I'm sure you can do some kind of artifact:install in order to put jars
> > > into your local repository (from your workspace). We could do that
> > > with MINA and perhaps filecontext.
> > >
> > > See the following link under "Installing and Deploying Your Own
> > Artifacts":
> > >
> > > http://maven.apache.org/ant-tasks.html
> > >
> > > The Maven experts will need to verify though!
> > >
> > > Steve.
> > >
> >
> >
> > --
> > Martin Ritchie
> >
>
>
Re: Re: svn commit: r475297 - /incubator/qpid/trunk/qpid/java/broker/src/org/apache/qpid/server/Main.java
Posted by Marnie McCormack <ma...@googlemail.com>.
IIRC when Steve initially proposed introducing maven to the project we had
some debate, but it seems like there might be limitations/constraints
imposed that we didn't understand (as a group).
I can also see, from Daniel's posts, that other projects who use maven would
like us to follow suit as it'll make their lives easier.
So, there are pros & cons. What I think would be very helpful though (as
others have indicated) is a list of the things we can't do with maven (that
might impact us) ? We can then agree a way round/accept the limitation/other
as appropriate.
I know there have been a few items discussed in previous threads, and I'm
not very clear on where these things are at e.g. resolved, tricky but
fixable or really not possible.
So, for example, javadoc inclusion, mina snapshot, etc.
One way to do make where we are with maven clear would be to raise JIRAs for
the outstanding items. That way we can all see where we are, and discuss
anything truly significant.
It may be that you've already been able to resolve the items on Martin's
list Steve ? No time pressure from my perspective, just a sense that we're
perhaps a bit muddy at the moment.
Also Steve - if you could still do with a hand, JIRAs would be a good way to
get others involved now that M1 is pretty much done ?
Regards,
Marnie
On 11/15/06, Martin Ritchie <ri...@apache.org> wrote:
>
> I really hope that we don't have to rely on publicly available
> releases. What if a bug in one of our dependencies prevents us
> releasing because we have to wait for them despite there being a well
> used patch available? Do other OS projects just wait for their
> dependent projects to release? Does this approach foster a greater
> community as you have to help out projects you are dependent on?
> Fixing problems and release so that you can focus on your own
> projects.
>
> Such a limitation of maven which would have been good to know up front
> before we embarked on maven-ization. I'm really struggling to see what
> maven brings to the table.
>
> On 15/11/06, Steven Shaw <st...@gmail.com> wrote:
> > I'm sure you can do some kind of artifact:install in order to put jars
> > into your local repository (from your workspace). We could do that
> > with MINA and perhaps filecontext.
> >
> > See the following link under "Installing and Deploying Your Own
> Artifacts":
> >
> > http://maven.apache.org/ant-tasks.html
> >
> > The Maven experts will need to verify though!
> >
> > Steve.
> >
>
>
> --
> Martin Ritchie
>
Re: Re: svn commit: r475297 - /incubator/qpid/trunk/qpid/java/broker/src/org/apache/qpid/server/Main.java
Posted by Martin Ritchie <ri...@apache.org>.
I really hope that we don't have to rely on publicly available
releases. What if a bug in one of our dependencies prevents us
releasing because we have to wait for them despite there being a well
used patch available? Do other OS projects just wait for their
dependent projects to release? Does this approach foster a greater
community as you have to help out projects you are dependent on?
Fixing problems and release so that you can focus on your own
projects.
Such a limitation of maven which would have been good to know up front
before we embarked on maven-ization. I'm really struggling to see what
maven brings to the table.
On 15/11/06, Steven Shaw <st...@gmail.com> wrote:
> I'm sure you can do some kind of artifact:install in order to put jars
> into your local repository (from your workspace). We could do that
> with MINA and perhaps filecontext.
>
> See the following link under "Installing and Deploying Your Own Artifacts":
>
> http://maven.apache.org/ant-tasks.html
>
> The Maven experts will need to verify though!
>
> Steve.
>
--
Martin Ritchie
Re: svn commit: r475297 - /incubator/qpid/trunk/qpid/java/broker/src/org/apache/qpid/server/Main.java
Posted by Steven Shaw <st...@gmail.com>.
s/filecontext/fscontext/
Re: svn commit: r475297 - /incubator/qpid/trunk/qpid/java/broker/src/org/apache/qpid/server/Main.java
Posted by Steven Shaw <st...@gmail.com>.
I'm sure you can do some kind of artifact:install in order to put jars
into your local repository (from your workspace). We could do that
with MINA and perhaps filecontext.
See the following link under "Installing and Deploying Your Own Artifacts":
http://maven.apache.org/ant-tasks.html
The Maven experts will need to verify though!
Steve.
Re: svn commit: r475297 - /incubator/qpid/trunk/qpid/java/broker/src/org/apache/qpid/server/Main.java
Posted by Gordon Sim <gs...@redhat.com>.
Daniel Kulp wrote:
> On Wednesday November 15 2006 12:15 pm, Martin Ritchie wrote:
>> Is it not possible to use the snapshot we currently have in our
>> repository and distribute that in our release?
>
> Not for maven, no. It really must be in a public repository.
Are you saying it is not possible for maven to be used to build a
release that includes any jar file that is not published to a public
maven repository?
Re: svn commit: r475297 - /incubator/qpid/trunk/qpid/java/broker/src/org/apache/qpid/server/Main.java
Posted by Daniel Kulp <da...@iona.com>.
On Wednesday November 15 2006 12:15 pm, Martin Ritchie wrote:
> My appologies I didn't reallise you couldn't pickup the head of mina.
> I thought the snapshot you were using just vanished not the ability to
> get the head. We can of course revert all the mina changes I made but
> it would have been nice for a comment on the JIRA to help me
> understand that making the changes would not help the problem we are
> facing with maven.
From Maven, we CAN grab a SNAPSHOT version of a dependency if they publish
it to a SNAPSHOT repository. However, that will prevent us from being
able to release M2. The maven release plugin will flat out refuse to
build if there are SNAPSHOT dependencies.
> Annoying as it is there are a number of issues with mina 1.0.0 which
> the team are aware of and are trying to get a 1.0.1 release out soon.
> they have started the process but need to get their maven building
> their artifacts correctly to suit the release process. (Something I'm
> sure we could all work together to sort.)
>
> Is it not possible to use the snapshot we currently have in our
> repository and distribute that in our release?
Not for maven, no. It really must be in a public repository. If you
need bugs fixed or other enhancements, you need to work with that other
project to get them to release a new version or patch or whatever and get
it publicly available.
> There will hopefully be some improvements to mina before M2 that will
> improve the performance of our IO layer, but it is unlikely that they
> will be in an official release at that point. Will we be unable to use
> thse items?
No, not for M2.
It's exteremely important to only be using RELEASED versions of other
artifacts, especially other Apache artifacts. That is actually one of
the nicest things (IMO) about maven is that it actually enforces at
release time that you aren't using some random SNAPSHOT that kills
reproducability.
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194 F:781-902-8001
daniel.kulp@iona.com
Re: svn commit: r475297 - /incubator/qpid/trunk/qpid/java/broker/src/org/apache/qpid/server/Main.java
Posted by Martin Ritchie <ri...@apache.org>.
My appologies I didn't reallise you couldn't pickup the head of mina.
I thought the snapshot you were using just vanished not the ability to
get the head. We can of course revert all the mina changes I made but
it would have been nice for a comment on the JIRA to help me
understand that making the changes would not help the problem we are
facing with maven.
Annoying as it is there are a number of issues with mina 1.0.0 which
the team are aware of and are trying to get a 1.0.1 release out soon.
they have started the process but need to get their maven building
their artifacts correctly to suit the release process. (Something I'm
sure we could all work together to sort.)
Is it not possible to use the snapshot we currently have in our
repository and distribute that in our release?
There will hopefully be some improvements to mina before M2 that will
improve the performance of our IO layer, but it is unlikely that they
will be in an official release at that point. Will we be unable to use
thse items?
--
Martin
On 15/11/06, Steve Vinoski <vi...@iona.com> wrote:
> I've seen several mina-related commits go by today related to bring
> code up to mina-HEAD, but I must admit I still don't understand the
> desire to be using code straight from mina that isn't available in a
> maven repository yet.
>
> The reason? Well, yesterday I thought we all agreed to mavenize the
> trunk after M1. These commits prevent that. We can't even be picking
> up mina snapshots, because we can't release M2 or another release
> with snapshot dependencies, unless of course those snapshots turn
> into real releases before M2.
>
> The mvn branch works with released mina 1.0.0. To the best of my
> knowledge, 1.0.0 is the latest official release of mina. I've stated
> that several times, but it just seems to be glossed over and ignored.
>
> What critical bugs are fixed by picking up mina-HEAD? Are they truly
> critical showstoppers that absolutely have to be in trunk today?
>
> --steve
>
> On my b
> On Nov 15, 2006, at 11:21 AM, ritchiem@apache.org wrote:
>
> > Author: ritchiem
> > Date: Wed Nov 15 08:21:02 2006
> > New Revision: 475297
> >
> > URL: http://svn.apache.org/viewvc?view=rev&rev=475297
> > Log:
> > Removed local development code that made it into the repository
> >
> > Modified:
> > incubator/qpid/trunk/qpid/java/broker/src/org/apache/qpid/
> > server/Main.java
> >
> > Modified: incubator/qpid/trunk/qpid/java/broker/src/org/apache/qpid/
> > server/Main.java
> > URL: http://svn.apache.org/viewvc/incubator/qpid/trunk/qpid/java/
> > broker/src/org/apache/qpid/server/Main.java?
> > view=diff&rev=475297&r1=475296&r2=475297
> > ======================================================================
> > ========
> > --- incubator/qpid/trunk/qpid/java/broker/src/org/apache/qpid/
> > server/Main.java (original)
> > +++ incubator/qpid/trunk/qpid/java/broker/src/org/apache/qpid/
> > server/Main.java Wed Nov 15 08:21:02 2006
> > @@ -320,19 +320,7 @@
> >
> > SocketSessionConfig sc;
> >
> > - //fixme improve get to use configuration
> > - if (connectorConfig.qpidNIO)
> > - {
> > - //FIXME - this needs to be sorted to use the new
> > Mina MultiThread SA.
> > - _logger.warn("Using Qpid NIO - DISABLED");
> > - //sconfig =
> > (org.apache.mina.transport.socket.nio.MultiThreadSocketAcceptorConfig)
> > acceptor.getDefaultConfig();
> > - //sc = (SocketSessionConfig)
> > sconfig.getSessionConfig();
> > - }
> > -// else
> > - {
> > - _logger.warn("Using Mina NIO");
> > - sc = (SocketSessionConfig)
> > acceptor.getSessionConfig();
> > - }
> > + sc = (SocketSessionConfig) acceptor.getSessionConfig();
> >
> > sc.setReceiveBufferSize
> > (connectorConfig.socketReceiveBufferSize);
> > sc.setSendBufferSize
> > (connectorConfig.socketWriteBuferSize);
> >
> >
>
>