You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Martin Ritchie <ri...@apache.org> on 2006/11/13 18:00:32 UTC
Maven build
Steve,
I'm getting the following error from mvn under cygwin.
command: "mvn"
.
.
.
[INFO] ----------------------------------------------------------------------------
[INFO] Building Qpid Broker
[INFO] task-segment: [install]
[INFO] ----------------------------------------------------------------------------
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
Downloading: https://maven-repository.dev.java.net/nonav/repository//org.apache.mina/poms/mina-java5
-1.0.0.pom
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Error building POM (may not be this project's POM).
Project ID: org.apache.mina:mina-java5
Reason: Error getting POM for 'org.apache.mina:mina-java5' from the
repository: Error transferring f
ile
org.apache.mina:mina-java5:pom:1.0.0
from the specified remote repositories:
central (http://repo1.maven.org/maven2),
java.net (https://maven-repository.dev.java.net/nonav/repository/),
apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository)
-----
The common bits seem to compile ok but the broker looks like it is
failing to download mina. I'm not to up on maven but hte three urls
don't seem to have the pom file.
I'm using:
maven 2.0.4
java 1.5.0_08
Any thoughts?
--
Martin Ritchie
Re: Maven build
Posted by Steve Vinoski <vi...@iona.com>.
On Nov 13, 2006, at 5:40 PM, Rajith Attapattu wrote:
> Steve,
>
> I really appreciate your effort So lets all aim to test it first thing
> tomorrow morning and then we can make a decesion about the release.
OK, there's still release-related work to do, but if you "svn up" the
mvn branch, you can do this:
cd branches/mvn
svn up
mvn
cd distribution
mvn
Assuming that all works for you, you'll find gzipped tar files and
such in the distribution/target directory. They still need work in
making sure everything is in there properly, but hopefully what's
currently there is enough to experiment with. I was able to untar the
bin.tar.gz file and get the broker running via the qpid-server
script, for example. If you run into troubles with anything, please
let me know, as I can probably turn fixes around reasonably quickly.
Rajith, note that I haven't picked up your Developing.txt/README.txt
change on this branch yet.
--steve
>
> Regards,
>
> Rajith
>
> On 11/13/06, Steve Vinoski <vi...@iona.com> wrote:
>>
>> On Nov 13, 2006, at 4:54 PM, Robert Greig wrote:
>>
>> > On 13/11/06, Steve Vinoski <vi...@iona.com> wrote:
>> >> > Is there a different goal to generate this?
>> >>
>> >> I've been so completely focused on getting the tests working
>> that I
>> >> haven't caught the maven work up on distribution building and
>> such.
>> >> Adding it won't be hard.
>> >
>> > How long do you expect it to take?
>>
>> I'll aim to have something ready by midnight to 1am Boston time.
>>
>> --steve
>>
>>
Re: Maven build
Posted by Rajith Attapattu <ra...@gmail.com>.
Steve,
I really appreciate your effort So lets all aim to test it first thing
tomorrow morning and then we can make a decesion about the release.
Regards,
Rajith
On 11/13/06, Steve Vinoski <vi...@iona.com> wrote:
>
> On Nov 13, 2006, at 4:54 PM, Robert Greig wrote:
>
> > On 13/11/06, Steve Vinoski <vi...@iona.com> wrote:
> >> > Is there a different goal to generate this?
> >>
> >> I've been so completely focused on getting the tests working that I
> >> haven't caught the maven work up on distribution building and such.
> >> Adding it won't be hard.
> >
> > How long do you expect it to take?
>
> I'll aim to have something ready by midnight to 1am Boston time.
>
> --steve
>
>
Re: Maven build
Posted by Steve Vinoski <vi...@iona.com>.
On Nov 13, 2006, at 4:54 PM, Robert Greig wrote:
> On 13/11/06, Steve Vinoski <vi...@iona.com> wrote:
>> > Is there a different goal to generate this?
>>
>> I've been so completely focused on getting the tests working that I
>> haven't caught the maven work up on distribution building and such.
>> Adding it won't be hard.
>
> How long do you expect it to take?
I'll aim to have something ready by midnight to 1am Boston time.
--steve
Re: Maven build
Posted by Robert Greig <ro...@gmail.com>.
On 13/11/06, Steve Vinoski <vi...@iona.com> wrote:
> > Is there a different goal to generate this?
>
> I've been so completely focused on getting the tests working that I
> haven't caught the maven work up on distribution building and such.
> Adding it won't be hard.
How long do you expect it to take?
RG
Re: Maven build
Posted by Steve Vinoski <vi...@iona.com>.
On Nov 13, 2006, at 4:23 PM, Robert Greig wrote:
> On 13/11/06, Steve Vinoski <vi...@iona.com> wrote:
>> On Nov 13, 2006, at 3:56 PM, Rajith Attapattu wrote:
>>
>> > It builds fine for me.
>> >
>> > Steve, are u going to have any tasks that moves the deployment
>> > artifacts to
>> > a top level target dir and also to create a source tar ball (and
>> > zip) ?
>>
>> Sure thing, we can add whatever is required. I based these pom files
>> on the CXF pom files, and we can probably borrow something suitable
>> from there.
>
> This may be a dumb question, but where does it put the binary
> distribution? I'm trying to test that all the scripts (e.g.
> qpid-server etc.) still work when we unzip/untar the distribution on
> Windows and Linux.
>
> Is there a different goal to generate this?
I've been so completely focused on getting the tests working that I
haven't caught the maven work up on distribution building and such.
Adding it won't be hard.
--steve
Re: Maven build
Posted by Robert Greig <ro...@gmail.com>.
On 13/11/06, Steve Vinoski <vi...@iona.com> wrote:
> On Nov 13, 2006, at 3:56 PM, Rajith Attapattu wrote:
>
> > It builds fine for me.
> >
> > Steve, are u going to have any tasks that moves the deployment
> > artifacts to
> > a top level target dir and also to create a source tar ball (and
> > zip) ?
>
> Sure thing, we can add whatever is required. I based these pom files
> on the CXF pom files, and we can probably borrow something suitable
> from there.
This may be a dumb question, but where does it put the binary
distribution? I'm trying to test that all the scripts (e.g.
qpid-server etc.) still work when we unzip/untar the distribution on
Windows and Linux.
Is there a different goal to generate this?
RG
Re: Maven build
Posted by Steve Vinoski <vi...@iona.com>.
On Nov 13, 2006, at 3:56 PM, Rajith Attapattu wrote:
> It builds fine for me.
>
> Steve, are u going to have any tasks that moves the deployment
> artifacts to
> a top level target dir and also to create a source tar ball (and
> zip) ?
Sure thing, we can add whatever is required. I based these pom files
on the CXF pom files, and we can probably borrow something suitable
from there.
--steve
>
> --Rajith
>
> On 11/13/06, Carl Trieloff <cc...@redhat.com> wrote:
>>
>>
>> I am seeing the same as what you are on the tests.
>>
>> Carl.
>>
>> Robert Greig wrote:
>> > On 13/11/06, Robert Greig <ro...@gmail.com> wrote:
>> >> I'll try again from my home machine.
>> >
>> > It builds on my home machine. We'll have to investigate what is
>> > happening behind our firewall although we did try navigating to the
>> > download sites in IE so it isn't a simple "cannot connect" issue.
>> >
>> > However the tests are hanging. I get a lot of
>> > java.util.concurrent.RejectedExecutionException. Carl, are you
>> seeing
>> > those in your logs or are you seeing different problems?
>> >
>> > RG
>>
>>
Re: Maven build
Posted by Rajith Attapattu <ra...@gmail.com>.
It builds fine for me.
Steve, are u going to have any tasks that moves the deployment artifacts to
a top level target dir and also to create a source tar ball (and zip) ?
--Rajith
On 11/13/06, Carl Trieloff <cc...@redhat.com> wrote:
>
>
> I am seeing the same as what you are on the tests.
>
> Carl.
>
> Robert Greig wrote:
> > On 13/11/06, Robert Greig <ro...@gmail.com> wrote:
> >> I'll try again from my home machine.
> >
> > It builds on my home machine. We'll have to investigate what is
> > happening behind our firewall although we did try navigating to the
> > download sites in IE so it isn't a simple "cannot connect" issue.
> >
> > However the tests are hanging. I get a lot of
> > java.util.concurrent.RejectedExecutionException. Carl, are you seeing
> > those in your logs or are you seeing different problems?
> >
> > RG
>
>
Re: Maven build
Posted by Carl Trieloff <cc...@redhat.com>.
I am seeing the same as what you are on the tests.
Carl.
Robert Greig wrote:
> On 13/11/06, Robert Greig <ro...@gmail.com> wrote:
>> I'll try again from my home machine.
>
> It builds on my home machine. We'll have to investigate what is
> happening behind our firewall although we did try navigating to the
> download sites in IE so it isn't a simple "cannot connect" issue.
>
> However the tests are hanging. I get a lot of
> java.util.concurrent.RejectedExecutionException. Carl, are you seeing
> those in your logs or are you seeing different problems?
>
> RG
Re: Maven build
Posted by John O'Hara <jo...@gmail.com>.
I'm not a certain IT security type :-)
John
On 14/11/06, Steve Vinoski <vi...@iona.com> wrote:
>
>
> On Nov 14, 2006, at 3:06 PM, John O'Hara wrote:
>
> > Behind corporate firewalls, Maven's repositories sometimes get
> > blocked.
> > A certain large bank I know blocks ibiblio's repository, amongst
> > others.
>
> We don't use ibiblio at all.
>
> > Having Maven pull stuff down for production builds causes certain IT
> > security types to wake up in a cold sweat.
>
> Why? The versions are all specified in the poms, and that's exactly
> what gets pulled down. It's not like the build is just grabbing
> random stuff. And if you really don't want anything to get downloaded
> for a certain build, type "mvn -o" (where 'o' stands for "offline").
> Personally, I think this gives "certain IT security types" more
> control, not less.
>
> > I don't know if this is what we're seeing here - but one to watch for.
>
> Hopefully the above explanations help ease these concerns.
>
> --steve
>
>
> >
> > John
> >
> >
> > On 13/11/06, Robert Greig <ro...@gmail.com> wrote:
> >>
> >> On 13/11/06, Robert Greig <ro...@gmail.com> wrote:
> >> > I'll try again from my home machine.
> >>
> >> It builds on my home machine. We'll have to investigate what is
> >> happening behind our firewall although we did try navigating to the
> >> download sites in IE so it isn't a simple "cannot connect" issue.
> >>
> >> However the tests are hanging. I get a lot of
> >> java.util.concurrent.RejectedExecutionException. Carl, are you seeing
> >> those in your logs or are you seeing different problems?
> >>
> >> RG
> >>
>
>
Re: Maven build
Posted by Steve Vinoski <vi...@iona.com>.
On Nov 14, 2006, at 3:06 PM, John O'Hara wrote:
> Behind corporate firewalls, Maven's repositories sometimes get
> blocked.
> A certain large bank I know blocks ibiblio's repository, amongst
> others.
We don't use ibiblio at all.
> Having Maven pull stuff down for production builds causes certain IT
> security types to wake up in a cold sweat.
Why? The versions are all specified in the poms, and that's exactly
what gets pulled down. It's not like the build is just grabbing
random stuff. And if you really don't want anything to get downloaded
for a certain build, type "mvn -o" (where 'o' stands for "offline").
Personally, I think this gives "certain IT security types" more
control, not less.
> I don't know if this is what we're seeing here - but one to watch for.
Hopefully the above explanations help ease these concerns.
--steve
>
> John
>
>
> On 13/11/06, Robert Greig <ro...@gmail.com> wrote:
>>
>> On 13/11/06, Robert Greig <ro...@gmail.com> wrote:
>> > I'll try again from my home machine.
>>
>> It builds on my home machine. We'll have to investigate what is
>> happening behind our firewall although we did try navigating to the
>> download sites in IE so it isn't a simple "cannot connect" issue.
>>
>> However the tests are hanging. I get a lot of
>> java.util.concurrent.RejectedExecutionException. Carl, are you seeing
>> those in your logs or are you seeing different problems?
>>
>> RG
>>
Re: Maven build
Posted by John O'Hara <jo...@gmail.com>.
Behind corporate firewalls, Maven's repositories sometimes get blocked.
A certain large bank I know blocks ibiblio's repository, amongst others.
Having Maven pull stuff down for production builds causes certain IT
security types to wake up in a cold sweat.
I don't know if this is what we're seeing here - but one to watch for.
John
On 13/11/06, Robert Greig <ro...@gmail.com> wrote:
>
> On 13/11/06, Robert Greig <ro...@gmail.com> wrote:
> > I'll try again from my home machine.
>
> It builds on my home machine. We'll have to investigate what is
> happening behind our firewall although we did try navigating to the
> download sites in IE so it isn't a simple "cannot connect" issue.
>
> However the tests are hanging. I get a lot of
> java.util.concurrent.RejectedExecutionException. Carl, are you seeing
> those in your logs or are you seeing different problems?
>
> RG
>
Re: Maven build
Posted by Robert Greig <ro...@gmail.com>.
On 13/11/06, Robert Greig <ro...@gmail.com> wrote:
> I'll try again from my home machine.
It builds on my home machine. We'll have to investigate what is
happening behind our firewall although we did try navigating to the
download sites in IE so it isn't a simple "cannot connect" issue.
However the tests are hanging. I get a lot of
java.util.concurrent.RejectedExecutionException. Carl, are you seeing
those in your logs or are you seeing different problems?
RG
Re: Maven build
Posted by Martin Ritchie <ri...@apache.org>.
If you run the ant task testreport you only get summary report
information on the test that is running. All output is logged to files
then rendered to a nice html site in build/<module>/test/report/junit
On 13/11/06, Robert Greig <ro...@gmail.com> wrote:
> On 13/11/06, Daniel Kulp <da...@iona.com> wrote:
>
> > You aren't using some out of date mirror in your settings.xml, are you?
>
> I don't know. How do I know what are up to date mirrors?
>
> > I'd try disabling any mirrors in your settings.xml and see if that helps.
>
> It does list the repos in the error message - do they look right?
>
> > You might want to "rm -rf ~/.m2/repository/org/apache/mina" and retry.
>
> I have done that - I have nuked the whole .m2 directory.
>
> I'll try again from my home machine.
>
> > I really don't
> > like the amount of crap going to stdout during the tests. (I'm a believer
> > that passing tests should do so SILENTLY. Only failing tests should
> > output stuff) However, that issue doesn't affect it actually building
> > and running.
>
> It should be log4j output, so you can change it by altering your log4j
> settings. Tests should not be using System.out directly but of course
> maybe some are inadvertantly. I personally find it very useful to be
> able to switch on some more output when tests are failing so that you
> can track down what is going on.
>
> RG
>
--
Martin Ritchie
Re: Maven build
Posted by Robert Greig <ro...@gmail.com>.
On 13/11/06, Daniel Kulp <da...@iona.com> wrote:
> You aren't using some out of date mirror in your settings.xml, are you?
I don't know. How do I know what are up to date mirrors?
> I'd try disabling any mirrors in your settings.xml and see if that helps.
It does list the repos in the error message - do they look right?
> You might want to "rm -rf ~/.m2/repository/org/apache/mina" and retry.
I have done that - I have nuked the whole .m2 directory.
I'll try again from my home machine.
> I really don't
> like the amount of crap going to stdout during the tests. (I'm a believer
> that passing tests should do so SILENTLY. Only failing tests should
> output stuff) However, that issue doesn't affect it actually building
> and running.
It should be log4j output, so you can change it by altering your log4j
settings. Tests should not be using System.out directly but of course
maybe some are inadvertantly. I personally find it very useful to be
able to switch on some more output when tests are failing so that you
can track down what is going on.
RG
Re: Maven build
Posted by Daniel Kulp <da...@iona.com>.
On Tuesday November 14 2006 11:51 am, Robert Greig wrote:
> On 14/11/06, Steve Vinoski <vi...@iona.com> wrote:
> > The big white elephant in the room here is that some here seem to
> > want M1 to be a release of the ant-based status quo, while others
> > want M1 to include maven for a variety of reasons, not the least of
> > which is that it we believe it's the right way forward for the Qpid
> > development community, represents how we think releases ought to be
> > done, shows that we're quickly and properly learning Apache
> > guidelines and practices, and avoids doing the same work two or more
> > times, first in ant then in maven.
>
> The funamental point is that whether it is built with ant or maven
> matters not one jot to our users. We would like to get M1 released so
> that we can move on and start focussing on adding functionality for
> M2.
>
> No one is debating whether we should move to maven it is only an issue
> of timing.
>
> RG
Well, define users.....
Two "potential" users, the tuscany and CXF communities, basically require
the proper artifacts be available in the m2 respositories. The easiest
and best way to do that is to use m2 to put them there. Thus, to meet
those users, we either spend a bit of effort to "manually" put them
there, hand code poms, etc... or spend a bit of effort to go all out to
maven.
Me: I'm completely +1 to delaying M1 until it can be produced with maven.
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194 F:781-902-8001
daniel.kulp@iona.com
Re: Maven build
Posted by John O'Hara <jo...@gmail.com>.
+1 for get something out asap to call M1; which to me means no Maven in M1.
Marnie is right, plus people all over the world are looking to grab some
Qpid goodness right now, but they don't know what to grab :-)
+1 that M2 should have the Maven based build system (we all agree it is good
stuff).
I think Carl's suggestion is a good one, since I would hope bug fix traffic
on an M1 label would be modest, which allows for the necessary carnage to
take place on the trunk to Mavenise Qpid.
We just need to make it very clear where M1 patches post release are going;
there is scope for confusion.
John
On 14/11/06, Carl Trieloff <cc...@redhat.com> wrote:
>
>
> I fully understand, that is why I was trying to get consensus. The issue
> is that when M1 punch list was build maven
> was not included. This might have been because Steve was on the road --
> the fact is that no one else added it for M1
>
> Anyway we have a situation where we completed all the JIRAs for M1 and
> as committers where trying to close down for RC
> when the maven for M1 discussion started. unfortunate...
>
> I understand the desire to get maven in, in M1. I also understand the
> desire to branch the mainline and move on. Somewhere
> someone has to give some goodwill --- worst case is that those that want
> maven in force a 3 day window for vote, --- then as those
> that want to keep moving still might not vote maven in for M1.
>
> Let's not use up all the good will and be pragmatic..
>
> To this end my a propose a third option:
> - branch to release what we have now (This is a good so that we can
> work through all the apache release procedures)
> - when we release C++ and other components in a few weeks time (maybe
> push back to Dec) we call it M2 and re-cut an update of Java
> - with maven + new code generators, persistence etc....
>
>
> Does this fly ?? if not suggest a variation.
>
> Carl.
>
>
>
> Daniel Kulp wrote:
> > Carl,
> >
> >
> >> I see we have two options:
> >> 1.) extend the time line
> >> 2.) Cut the release as using ant as in the vote thread (the key was to
> >> let Steve get the test refactor to main-line)
> >>
> > ....
> >
> >> I would like to get a show of hands on this point, and if I am correct
> >> in my assessment we should create the M1 branch with ant create the RC
> >> and give the team time to get up to speed with maven on mainline for M2
> >> and continue M2 development. Rajith can then create the branch and a
> >> signed RC later today that we can all test.
> >>
> >
> > I just want to point out that if a concensus isn't reached and a vote
> > needs to be called, that will delay M1 for at least another 3 days as
> the
> > vote MUST be run for 72 hours. In those 3 days, most of the maven
> > issues could be fixed.
> >
> >
> >
> >> Please can you show your level of comfort including maven (release
> >> maven branch) or ant build for M1 (1 line answers so that we can
> >> easily see where the committers are at)
> >>
> >
> > I'm -1 (non-binding) to releasing with Ant as that would mean other
> > projects would not be able to take dependencies on it. (unless someone
> > spends some time getting the ant build to generate maven artifacts,
> which
> > would be a stupid waste of time) Since I'm a commiter on at least two
> > such projects, I say spend the time getting maven working.
> >
> >
> >
>
>
>
Re: Maven build
Posted by Marnie McCormack <ma...@googlemail.com>.
Rajith/Carl/Steve,
I'm happy if we can agree to cut M1 now thanks.
I have no strong opinions about M2 in terms of timing or content - assuming
we can reach a sensible idea of when it might be cut-able and see where
we're likely to be at. Since we've done a lot of the legal work etc for M1,
then I'd hope M2 should be straightforward and if Steve is willing to
release manage then that sounds good.
I'd emailed Carl previously about switching on JIRA time tracking to allow
us to add/track work outstanding (estimates) on tasks. This could
potentially be quite useful in terms of doing sensible scoping for the next
releases.
Rajith - let me know if I can help in any way. I'm not in the office until
Thurs but will pick up my mail.
Enjoying the more reflected debate.
Thanks & Regards,
Marnie
On 11/15/06, Daniel Kulp <da...@iona.com> wrote:
>
> Rajith,
>
>
> > It looks like we are comming towards some concensus on the M1 release.
> > If there are no objections, I will cut a release candidate first thing
> > tomorrow morning.
> >
> > I would also like to propose an informal code freeze, so as to not rock
> > the boat by checking in any significant changes.
> > From now on until we cut the final release only critical bug fixes or
> > infrastrucutre details (license ..etc) should be checked in.
>
> In general, locking trunk for any significant amount of time is
> discouraged. Any of the commiters should be allowed to commit to trunk
> at any time. If a commiter goes on vacation for month and comes back,
> they should be able to pick up right where they left off with any stuff
> they were working on without worry about if a release is locking the
> trunk or not.
>
> If you need control in order to do a release, it is recommended to create
> a release branch and, as the release manager, selectively merge changes
> from trunk to the release branch if those commits meet your requirements
> for your release. No one said being a release manager is an easy
> job. :-)
>
> That all said, I would probably ask (politely) Steve to hold off on
> merging the maven stuff to trunk for a few days. Those changes are huge
> and would make other changes hard to merge to your release branch.
>
> The httpd project has a very good page describing their processes for the
> release manager:
> http://httpd.apache.org/dev/release.html
> In particular, read the section entitled:
> "How does an impending release affect development?"
>
> Enjoy!
> Dan
>
>
> > Once we cut the RC, I would expect some through testing to ensure we
> > want to move towards the M1 release.
> > I am open to suggestions as to how long we should have the RC around
> > before we cut the final release.
> >
> > Regards,
> >
> > Rajith
> >
> > On 11/14/06, Martin Ritchie <ri...@apache.org> wrote:
> > > Just before close of day I just wanted to add my 2¢.
> > >
> > > Just picking up from conversations since 5pm.
> > >
> > > The only thing that is missing from the head ant build is the
> > > separate preparation of client zip and tgz. I have the changes ready
> > > to commit but have not committed them until the M1 situation is
> > > resolved.
> > >
> > > I am very much in favour of releasing now as we are passed a well
> > > publicised deadline for M1 issues listed in JIRA. I think the idea of
> > > understanding the release process with this M1 java/python/ruby will
> > > be very informative and by the time it is done we will be near
> > > Christmas and have the new persistence model and a fully maven-ized
> > > truck that will be real value add for our clients/users and be a
> > > perfect time to M2 the entire project.
> > >
> > > I for one have not had much input on the maven branch as I have far
> > > more experience with ant but the coming weeks of maven-ization of the
> > > truck will help me understand more and give me time to aid resolving
> > > any issues that exist.
> > >
> > > I would really like to see us all working together as a cohesive
> > > project, which is what incubation diversity is all about, as I
> > > understand it.
> > >
> > > I think we all value the initial work that Steve has put in to
> > > getting maven working on the trunk. I just feel it is important for
> > > the project going forward that we have set goals that are clearly
> > > defined in JIRAs so that the community can see our direction and we
> > > can all understand when we are ready for next release.
> > >
> > > This will prevent any one party trying to add in new features before
> > > a release deadline unless the there is a binding vote that says
> > > otherwise.
> > >
> > > This is the only way that I can see to work if graduation from the
> > > incubator is our goal.
> > >
> > > --
> > > Martin
> > >
> > > On 14/11/06, Robert Greig <ro...@gmail.com> wrote:
> > > > On 14/11/06, Steve Vinoski <vi...@iona.com> wrote:
> > > > > I was about to respond with a similar suggestion, but even less
> > > > > aggressive in terms of features. What we'd like to see is an M2
> > > > > starting essentially right away, shortly after Rajith branches
> > > > > for M1. We'd like to scope M2 to include maven, along with a move
> > > > > to junit3 so as to enhance the effectiveness of maven and enforce
> > > > > the jdk 1.4 constraint for client.
> > > >
> > > > What kind of timescale do you think is realistic for M2? My only
> > > > issue with the above is that it does not offer anything in the way
> > > > of extra functionality for our users so if due to the overhead of
> > > > the Apache release process that took a while we would be spending
> > > > time on admin etc.
> > > >
> > > > It's tangential to this discussion but for jdk 1.4 support IIRC
> > > > there was discussion about use of Retroweaver. I believe it would
> > > > actually be nice to further consolidate broker and client code
> > > > (there is stuff that is basically duplication) and that implies 1.5
> > > > source.
> > > >
> > > > > What would specifically *not* be in M2, however, would be a move
> > > > > to the new rev of AMQP -- we'd push that off to M3 (note BTW that
> > > > > this requires going through JIRA to move all relevant issues
> > > > > related to AMQP version from M2 to M3).
> > > >
> > > > Yes, agreed.
> > > >
> > > > > Whether persistence and JMS could be in the picture, I hadn't
> > > > > considered. I don't know how close persistence is, nor how much
> > > > > work the JMS stuff is, but we can certainly talk about that.
> > > >
> > > > I will be able to give a better indication later this week on how I
> > > > think persistence is going (I think it's going well but wouldn't
> > > > want to state anything categorical until I had joined up all the
> > > > dots, and got some feedback from someone else).
> > > >
> > > > RG
>
> --
> J. Daniel Kulp
> Principal Engineer
> IONA
> P: 781-902-8727 C: 508-380-7194 F:781-902-8001
> daniel.kulp@iona.com
>
Re: Maven build
Posted by Daniel Kulp <da...@iona.com>.
Rajith,
> It looks like we are comming towards some concensus on the M1 release.
> If there are no objections, I will cut a release candidate first thing
> tomorrow morning.
>
> I would also like to propose an informal code freeze, so as to not rock
> the boat by checking in any significant changes.
> From now on until we cut the final release only critical bug fixes or
> infrastrucutre details (license ..etc) should be checked in.
In general, locking trunk for any significant amount of time is
discouraged. Any of the commiters should be allowed to commit to trunk
at any time. If a commiter goes on vacation for month and comes back,
they should be able to pick up right where they left off with any stuff
they were working on without worry about if a release is locking the
trunk or not.
If you need control in order to do a release, it is recommended to create
a release branch and, as the release manager, selectively merge changes
from trunk to the release branch if those commits meet your requirements
for your release. No one said being a release manager is an easy
job. :-)
That all said, I would probably ask (politely) Steve to hold off on
merging the maven stuff to trunk for a few days. Those changes are huge
and would make other changes hard to merge to your release branch.
The httpd project has a very good page describing their processes for the
release manager:
http://httpd.apache.org/dev/release.html
In particular, read the section entitled:
"How does an impending release affect development?"
Enjoy!
Dan
> Once we cut the RC, I would expect some through testing to ensure we
> want to move towards the M1 release.
> I am open to suggestions as to how long we should have the RC around
> before we cut the final release.
>
> Regards,
>
> Rajith
>
> On 11/14/06, Martin Ritchie <ri...@apache.org> wrote:
> > Just before close of day I just wanted to add my 2¢.
> >
> > Just picking up from conversations since 5pm.
> >
> > The only thing that is missing from the head ant build is the
> > separate preparation of client zip and tgz. I have the changes ready
> > to commit but have not committed them until the M1 situation is
> > resolved.
> >
> > I am very much in favour of releasing now as we are passed a well
> > publicised deadline for M1 issues listed in JIRA. I think the idea of
> > understanding the release process with this M1 java/python/ruby will
> > be very informative and by the time it is done we will be near
> > Christmas and have the new persistence model and a fully maven-ized
> > truck that will be real value add for our clients/users and be a
> > perfect time to M2 the entire project.
> >
> > I for one have not had much input on the maven branch as I have far
> > more experience with ant but the coming weeks of maven-ization of the
> > truck will help me understand more and give me time to aid resolving
> > any issues that exist.
> >
> > I would really like to see us all working together as a cohesive
> > project, which is what incubation diversity is all about, as I
> > understand it.
> >
> > I think we all value the initial work that Steve has put in to
> > getting maven working on the trunk. I just feel it is important for
> > the project going forward that we have set goals that are clearly
> > defined in JIRAs so that the community can see our direction and we
> > can all understand when we are ready for next release.
> >
> > This will prevent any one party trying to add in new features before
> > a release deadline unless the there is a binding vote that says
> > otherwise.
> >
> > This is the only way that I can see to work if graduation from the
> > incubator is our goal.
> >
> > --
> > Martin
> >
> > On 14/11/06, Robert Greig <ro...@gmail.com> wrote:
> > > On 14/11/06, Steve Vinoski <vi...@iona.com> wrote:
> > > > I was about to respond with a similar suggestion, but even less
> > > > aggressive in terms of features. What we'd like to see is an M2
> > > > starting essentially right away, shortly after Rajith branches
> > > > for M1. We'd like to scope M2 to include maven, along with a move
> > > > to junit3 so as to enhance the effectiveness of maven and enforce
> > > > the jdk 1.4 constraint for client.
> > >
> > > What kind of timescale do you think is realistic for M2? My only
> > > issue with the above is that it does not offer anything in the way
> > > of extra functionality for our users so if due to the overhead of
> > > the Apache release process that took a while we would be spending
> > > time on admin etc.
> > >
> > > It's tangential to this discussion but for jdk 1.4 support IIRC
> > > there was discussion about use of Retroweaver. I believe it would
> > > actually be nice to further consolidate broker and client code
> > > (there is stuff that is basically duplication) and that implies 1.5
> > > source.
> > >
> > > > What would specifically *not* be in M2, however, would be a move
> > > > to the new rev of AMQP -- we'd push that off to M3 (note BTW that
> > > > this requires going through JIRA to move all relevant issues
> > > > related to AMQP version from M2 to M3).
> > >
> > > Yes, agreed.
> > >
> > > > Whether persistence and JMS could be in the picture, I hadn't
> > > > considered. I don't know how close persistence is, nor how much
> > > > work the JMS stuff is, but we can certainly talk about that.
> > >
> > > I will be able to give a better indication later this week on how I
> > > think persistence is going (I think it's going well but wouldn't
> > > want to state anything categorical until I had joined up all the
> > > dots, and got some feedback from someone else).
> > >
> > > RG
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194 F:781-902-8001
daniel.kulp@iona.com
Re: Maven build
Posted by Carl Trieloff <cc...@redhat.com>.
Very well put..
Martin Ritchie wrote:
> Just before close of day I just wanted to add my 2¢.
>
> Just picking up from conversations since 5pm.
>
> The only thing that is missing from the head ant build is the separate
> preparation of client zip and tgz. I have the changes ready to commit
> but have not committed them until the M1 situation is resolved.
>
> I am very much in favour of releasing now as we are passed a well
> publicised deadline for M1 issues listed in JIRA. I think the idea of
> understanding the release process with this M1 java/python/ruby will
> be very informative and by the time it is done we will be near
> Christmas and have the new persistence model and a fully maven-ized
> truck that will be real value add for our clients/users and be a
> perfect time to M2 the entire project.
>
> I for one have not had much input on the maven branch as I have far
> more experience with ant but the coming weeks of maven-ization of the
> truck will help me understand more and give me time to aid resolving
> any issues that exist.
>
> I would really like to see us all working together as a cohesive
> project, which is what incubation diversity is all about, as I
> understand it.
>
> I think we all value the initial work that Steve has put in to getting
> maven working on the trunk. I just feel it is important for the
> project going forward that we have set goals that are clearly defined
> in JIRAs so that the community can see our direction and we can all
> understand when we are ready for next release.
>
> This will prevent any one party trying to add in new features before a
> release deadline unless the there is a binding vote that says
> otherwise.
>
> This is the only way that I can see to work if graduation from the
> incubator is our goal.
>
Re: Re: Maven build
Posted by Rajith Attapattu <ra...@gmail.com>.
Hi Folks,
It looks like we are comming towards some concensus on the M1 release.
If there are no objections, I will cut a release candidate first thing
tomorrow morning.
I would also like to propose an informal code freeze, so as to not rock the
boat by checking in any significant changes.
>From now on until we cut the final release only critical bug fixes or
infrastrucutre details (license ..etc) should be checked in.
Once we cut the RC, I would expect some through testing to ensure we want to
move towards the M1 release.
I am open to suggestions as to how long we should have the RC around before
we cut the final release.
Regards,
Rajith
On 11/14/06, Martin Ritchie <ri...@apache.org> wrote:
>
> Just before close of day I just wanted to add my 2¢.
>
> Just picking up from conversations since 5pm.
>
> The only thing that is missing from the head ant build is the separate
> preparation of client zip and tgz. I have the changes ready to commit
> but have not committed them until the M1 situation is resolved.
>
> I am very much in favour of releasing now as we are passed a well
> publicised deadline for M1 issues listed in JIRA. I think the idea of
> understanding the release process with this M1 java/python/ruby will
> be very informative and by the time it is done we will be near
> Christmas and have the new persistence model and a fully maven-ized
> truck that will be real value add for our clients/users and be a
> perfect time to M2 the entire project.
>
> I for one have not had much input on the maven branch as I have far
> more experience with ant but the coming weeks of maven-ization of the
> truck will help me understand more and give me time to aid resolving
> any issues that exist.
>
> I would really like to see us all working together as a cohesive
> project, which is what incubation diversity is all about, as I
> understand it.
>
> I think we all value the initial work that Steve has put in to getting
> maven working on the trunk. I just feel it is important for the
> project going forward that we have set goals that are clearly defined
> in JIRAs so that the community can see our direction and we can all
> understand when we are ready for next release.
>
> This will prevent any one party trying to add in new features before a
> release deadline unless the there is a binding vote that says
> otherwise.
>
> This is the only way that I can see to work if graduation from the
> incubator is our goal.
>
> --
> Martin
>
> On 14/11/06, Robert Greig <ro...@gmail.com> wrote:
> > On 14/11/06, Steve Vinoski <vi...@iona.com> wrote:
> >
> > > I was about to respond with a similar suggestion, but even less
> > > aggressive in terms of features. What we'd like to see is an M2
> > > starting essentially right away, shortly after Rajith branches for
> > > M1. We'd like to scope M2 to include maven, along with a move to
> > > junit3 so as to enhance the effectiveness of maven and enforce the
> > > jdk 1.4 constraint for client.
> >
> > What kind of timescale do you think is realistic for M2? My only issue
> > with the above is that it does not offer anything in the way of extra
> > functionality for our users so if due to the overhead of the Apache
> > release process that took a while we would be spending time on admin
> > etc.
> >
> > It's tangential to this discussion but for jdk 1.4 support IIRC there
> > was discussion about use of Retroweaver. I believe it would actually
> > be nice to further consolidate broker and client code (there is stuff
> > that is basically duplication) and that implies 1.5 source.
> >
> > > What would specifically *not* be in M2, however, would be a move to
> > > the new rev of AMQP -- we'd push that off to M3 (note BTW that this
> > > requires going through JIRA to move all relevant issues related to
> > > AMQP version from M2 to M3).
> >
> > Yes, agreed.
> >
> > > Whether persistence and JMS could be in the picture, I hadn't
> > > considered. I don't know how close persistence is, nor how much work
> > > the JMS stuff is, but we can certainly talk about that.
> >
> > I will be able to give a better indication later this week on how I
> > think persistence is going (I think it's going well but wouldn't want
> > to state anything categorical until I had joined up all the dots, and
> > got some feedback from someone else).
> >
> > RG
> >
>
Re: Re: Maven build
Posted by Martin Ritchie <ri...@apache.org>.
Just before close of day I just wanted to add my 2¢.
Just picking up from conversations since 5pm.
The only thing that is missing from the head ant build is the separate
preparation of client zip and tgz. I have the changes ready to commit
but have not committed them until the M1 situation is resolved.
I am very much in favour of releasing now as we are passed a well
publicised deadline for M1 issues listed in JIRA. I think the idea of
understanding the release process with this M1 java/python/ruby will
be very informative and by the time it is done we will be near
Christmas and have the new persistence model and a fully maven-ized
truck that will be real value add for our clients/users and be a
perfect time to M2 the entire project.
I for one have not had much input on the maven branch as I have far
more experience with ant but the coming weeks of maven-ization of the
truck will help me understand more and give me time to aid resolving
any issues that exist.
I would really like to see us all working together as a cohesive
project, which is what incubation diversity is all about, as I
understand it.
I think we all value the initial work that Steve has put in to getting
maven working on the trunk. I just feel it is important for the
project going forward that we have set goals that are clearly defined
in JIRAs so that the community can see our direction and we can all
understand when we are ready for next release.
This will prevent any one party trying to add in new features before a
release deadline unless the there is a binding vote that says
otherwise.
This is the only way that I can see to work if graduation from the
incubator is our goal.
--
Martin
On 14/11/06, Robert Greig <ro...@gmail.com> wrote:
> On 14/11/06, Steve Vinoski <vi...@iona.com> wrote:
>
> > I was about to respond with a similar suggestion, but even less
> > aggressive in terms of features. What we'd like to see is an M2
> > starting essentially right away, shortly after Rajith branches for
> > M1. We'd like to scope M2 to include maven, along with a move to
> > junit3 so as to enhance the effectiveness of maven and enforce the
> > jdk 1.4 constraint for client.
>
> What kind of timescale do you think is realistic for M2? My only issue
> with the above is that it does not offer anything in the way of extra
> functionality for our users so if due to the overhead of the Apache
> release process that took a while we would be spending time on admin
> etc.
>
> It's tangential to this discussion but for jdk 1.4 support IIRC there
> was discussion about use of Retroweaver. I believe it would actually
> be nice to further consolidate broker and client code (there is stuff
> that is basically duplication) and that implies 1.5 source.
>
> > What would specifically *not* be in M2, however, would be a move to
> > the new rev of AMQP -- we'd push that off to M3 (note BTW that this
> > requires going through JIRA to move all relevant issues related to
> > AMQP version from M2 to M3).
>
> Yes, agreed.
>
> > Whether persistence and JMS could be in the picture, I hadn't
> > considered. I don't know how close persistence is, nor how much work
> > the JMS stuff is, but we can certainly talk about that.
>
> I will be able to give a better indication later this week on how I
> think persistence is going (I think it's going well but wouldn't want
> to state anything categorical until I had joined up all the dots, and
> got some feedback from someone else).
>
> RG
>
Re: Maven build
Posted by Robert Greig <ro...@gmail.com>.
On 14/11/06, Steve Vinoski <vi...@iona.com> wrote:
> I was about to respond with a similar suggestion, but even less
> aggressive in terms of features. What we'd like to see is an M2
> starting essentially right away, shortly after Rajith branches for
> M1. We'd like to scope M2 to include maven, along with a move to
> junit3 so as to enhance the effectiveness of maven and enforce the
> jdk 1.4 constraint for client.
What kind of timescale do you think is realistic for M2? My only issue
with the above is that it does not offer anything in the way of extra
functionality for our users so if due to the overhead of the Apache
release process that took a while we would be spending time on admin
etc.
It's tangential to this discussion but for jdk 1.4 support IIRC there
was discussion about use of Retroweaver. I believe it would actually
be nice to further consolidate broker and client code (there is stuff
that is basically duplication) and that implies 1.5 source.
> What would specifically *not* be in M2, however, would be a move to
> the new rev of AMQP -- we'd push that off to M3 (note BTW that this
> requires going through JIRA to move all relevant issues related to
> AMQP version from M2 to M3).
Yes, agreed.
> Whether persistence and JMS could be in the picture, I hadn't
> considered. I don't know how close persistence is, nor how much work
> the JMS stuff is, but we can certainly talk about that.
I will be able to give a better indication later this week on how I
think persistence is going (I think it's going well but wouldn't want
to state anything categorical until I had joined up all the dots, and
got some feedback from someone else).
RG
Re: M2
Posted by Marnie McCormack <ma...@googlemail.com>.
Sounds a good way forward - sorry, should've sent my reply to the M1 thread
to this thread :-)
Marnie
On 11/15/06, Carl Trieloff <cc...@redhat.com> wrote:
>
>
> Thread name change - new topic..
>
>
> To add to John's comments... if we are on option 3 (consensus holds
> tomorrow) we should do a M2 with all the other pieces also. like end of
> year time frame. We should include all the meaningful merges and some
> JIRA's, but doubt that any of the next publication of the spec will be
> included as the publication date will be to late to include in this
> version. -- agree again.
>
> In addition to persistence, new code generators, obviously maven, and
> some JMS fixes that can complete should go in.
> HA requires the spec update so that will need to be done Q1 with
> protocol update.
>
> Let's plan to start reworking M2 JIRA's later this week
> Carl.
>
>
> John O'Hara wrote:
> > If I understand Rob, persistence is looking pretty good.
> > So an M2 for Christmas might be worth just persistence and Maven.
> > Nailing JMS might be a long piece of string depending on how TCK testing
> > goes. I wouldn't bet on that for Christmas.
> >
> > M1 - something that works
> > M2 - works with persistence, builds purdy
> >
>
>
M2
Posted by Carl Trieloff <cc...@redhat.com>.
Thread name change - new topic..
To add to John's comments... if we are on option 3 (consensus holds
tomorrow) we should do a M2 with all the other pieces also. like end of
year time frame. We should include all the meaningful merges and some
JIRA's, but doubt that any of the next publication of the spec will be
included as the publication date will be to late to include in this
version. -- agree again.
In addition to persistence, new code generators, obviously maven, and
some JMS fixes that can complete should go in.
HA requires the spec update so that will need to be done Q1 with
protocol update.
Let's plan to start reworking M2 JIRA's later this week
Carl.
John O'Hara wrote:
> If I understand Rob, persistence is looking pretty good.
> So an M2 for Christmas might be worth just persistence and Maven.
> Nailing JMS might be a long piece of string depending on how TCK testing
> goes. I wouldn't bet on that for Christmas.
>
> M1 - something that works
> M2 - works with persistence, builds purdy
>
Re: Maven build
Posted by John O'Hara <jo...@gmail.com>.
I know this is probably not the place, but it looks like more contributions
are being found in the transport proposals for AMQP's next revision. Its
important that's right, and undoubtedly some prototyping work will have to
be done on some code *branch* to test the concepts.
I'm kind of thinking that any transport changes should be targetted at
whatever release is the start of HA, since the killer features of the
revised transport are better support for HA. That might be M4.
If I understand Rob, persistence is looking pretty good.
So an M2 for Christmas might be worth just persistence and Maven.
Nailing JMS might be a long piece of string depending on how TCK testing
goes. I wouldn't bet on that for Christmas.
M1 - something that works
M2 - works with persistence, builds purdy
M3 - JMS'ified, perhaps protocol changes
M4 - HA
Being good first, then being great gets my vote.
HA should be a cut all of its own, and we should have a solid conceptual
foundation before going there. HA will expose any weaknesses in the
protocol and in Qpid very quickly.
John
On 14/11/06, Steve Vinoski <vi...@iona.com> wrote:
>
> On Nov 14, 2006, at 3:42 PM, Robert Greig wrote:
>
> > On 14/11/06, Carl Trieloff <cc...@redhat.com> wrote:
> >
> >> To this end my a propose a third option:
> >> - branch to release what we have now (This is a good so that we can
> >> work through all the apache release procedures)
> >> - when we release C++ and other components in a few weeks time
> >> (maybe
> >> push back to Dec) we call it M2 and re-cut an update of Java
> >> - with maven + new code generators, persistence etc....
> >
> > This works for me. I was going to propose (after M1 was out of the
> > way) that M2 was scoped to be maven, persistence and as many JMS
> > compliance improvements as we could achieve. That would push the major
> > HA and protocol changes into an M3 in January.
>
> I was about to respond with a similar suggestion, but even less
> aggressive in terms of features. What we'd like to see is an M2
> starting essentially right away, shortly after Rajith branches for
> M1. We'd like to scope M2 to include maven, along with a move to
> junit3 so as to enhance the effectiveness of maven and enforce the
> jdk 1.4 constraint for client.
>
> What would specifically *not* be in M2, however, would be a move to
> the new rev of AMQP -- we'd push that off to M3 (note BTW that this
> requires going through JIRA to move all relevant issues related to
> AMQP version from M2 to M3).
>
> Whether persistence and JMS could be in the picture, I hadn't
> considered. I don't know how close persistence is, nor how much work
> the JMS stuff is, but we can certainly talk about that.
>
> Like the issue that Marnie and John raised earlier, where a certain
> party is looking for an M1 based on what's there today, we have other
> parties looking for a mavenized release very soon based on the
> current version of AMQP. Hopefully we can all help each other out,
> rather than arguing and all of us losing as a result.
>
> Note that there's nothing that prohibits us from starting an M2
> immediately after M1.
>
> > I was hoping that we could get that M2 out in December (although
> > realistically I had thought mid-December). The motivation for that is
> > that we have a major project that does not require HA but does need
> > the persistence changes and I imagine their needs are not unique.
>
> I like the December target date for M2. However, just be aware that
> the Apache release process can be long and drawn out. It can take
> many weeks. For example, Yoko has been trying to get a release out
> for about the past 10 weeks. It takes a minimum of a 3-day vote in
> this group followed by a 3-day vote by the incubator PMC to get a
> release, and pretty much nobody gets it right the first time, meaning
> that this 6-7 day process usually has to be repeated several times.
>
> I would even volunteer to serve as M2 release manager.
>
> Thoughts?
>
> --steve
>
Re: Maven build
Posted by Steve Vinoski <vi...@iona.com>.
On Nov 14, 2006, at 3:42 PM, Robert Greig wrote:
> On 14/11/06, Carl Trieloff <cc...@redhat.com> wrote:
>
>> To this end my a propose a third option:
>> - branch to release what we have now (This is a good so that we can
>> work through all the apache release procedures)
>> - when we release C++ and other components in a few weeks time
>> (maybe
>> push back to Dec) we call it M2 and re-cut an update of Java
>> - with maven + new code generators, persistence etc....
>
> This works for me. I was going to propose (after M1 was out of the
> way) that M2 was scoped to be maven, persistence and as many JMS
> compliance improvements as we could achieve. That would push the major
> HA and protocol changes into an M3 in January.
I was about to respond with a similar suggestion, but even less
aggressive in terms of features. What we'd like to see is an M2
starting essentially right away, shortly after Rajith branches for
M1. We'd like to scope M2 to include maven, along with a move to
junit3 so as to enhance the effectiveness of maven and enforce the
jdk 1.4 constraint for client.
What would specifically *not* be in M2, however, would be a move to
the new rev of AMQP -- we'd push that off to M3 (note BTW that this
requires going through JIRA to move all relevant issues related to
AMQP version from M2 to M3).
Whether persistence and JMS could be in the picture, I hadn't
considered. I don't know how close persistence is, nor how much work
the JMS stuff is, but we can certainly talk about that.
Like the issue that Marnie and John raised earlier, where a certain
party is looking for an M1 based on what's there today, we have other
parties looking for a mavenized release very soon based on the
current version of AMQP. Hopefully we can all help each other out,
rather than arguing and all of us losing as a result.
Note that there's nothing that prohibits us from starting an M2
immediately after M1.
> I was hoping that we could get that M2 out in December (although
> realistically I had thought mid-December). The motivation for that is
> that we have a major project that does not require HA but does need
> the persistence changes and I imagine their needs are not unique.
I like the December target date for M2. However, just be aware that
the Apache release process can be long and drawn out. It can take
many weeks. For example, Yoko has been trying to get a release out
for about the past 10 weeks. It takes a minimum of a 3-day vote in
this group followed by a 3-day vote by the incubator PMC to get a
release, and pretty much nobody gets it right the first time, meaning
that this 6-7 day process usually has to be repeated several times.
I would even volunteer to serve as M2 release manager.
Thoughts?
--steve
Re: Maven build
Posted by Robert Greig <ro...@gmail.com>.
On 14/11/06, Carl Trieloff <cc...@redhat.com> wrote:
> To this end my a propose a third option:
> - branch to release what we have now (This is a good so that we can
> work through all the apache release procedures)
> - when we release C++ and other components in a few weeks time (maybe
> push back to Dec) we call it M2 and re-cut an update of Java
> - with maven + new code generators, persistence etc....
This works for me. I was going to propose (after M1 was out of the
way) that M2 was scoped to be maven, persistence and as many JMS
compliance improvements as we could achieve. That would push the major
HA and protocol changes into an M3 in January.
I was hoping that we could get that M2 out in December (although
realistically I had thought mid-December). The motivation for that is
that we have a major project that does not require HA but does need
the persistence changes and I imagine their needs are not unique.
RG
Re: Maven build
Posted by Carl Trieloff <cc...@redhat.com>.
I fully understand, that is why I was trying to get consensus. The issue
is that when M1 punch list was build maven
was not included. This might have been because Steve was on the road --
the fact is that no one else added it for M1
Anyway we have a situation where we completed all the JIRAs for M1 and
as committers where trying to close down for RC
when the maven for M1 discussion started. unfortunate...
I understand the desire to get maven in, in M1. I also understand the
desire to branch the mainline and move on. Somewhere
someone has to give some goodwill --- worst case is that those that want
maven in force a 3 day window for vote, --- then as those
that want to keep moving still might not vote maven in for M1.
Let's not use up all the good will and be pragmatic..
To this end my a propose a third option:
- branch to release what we have now (This is a good so that we can
work through all the apache release procedures)
- when we release C++ and other components in a few weeks time (maybe
push back to Dec) we call it M2 and re-cut an update of Java
- with maven + new code generators, persistence etc....
Does this fly ?? if not suggest a variation.
Carl.
Daniel Kulp wrote:
> Carl,
>
>
>> I see we have two options:
>> 1.) extend the time line
>> 2.) Cut the release as using ant as in the vote thread (the key was to
>> let Steve get the test refactor to main-line)
>>
> ....
>
>> I would like to get a show of hands on this point, and if I am correct
>> in my assessment we should create the M1 branch with ant create the RC
>> and give the team time to get up to speed with maven on mainline for M2
>> and continue M2 development. Rajith can then create the branch and a
>> signed RC later today that we can all test.
>>
>
> I just want to point out that if a concensus isn't reached and a vote
> needs to be called, that will delay M1 for at least another 3 days as the
> vote MUST be run for 72 hours. In those 3 days, most of the maven
> issues could be fixed.
>
>
>
>> Please can you show your level of comfort including maven (release
>> maven branch) or ant build for M1 (1 line answers so that we can
>> easily see where the committers are at)
>>
>
> I'm -1 (non-binding) to releasing with Ant as that would mean other
> projects would not be able to take dependencies on it. (unless someone
> spends some time getting the ant build to generate maven artifacts, which
> would be a stupid waste of time) Since I'm a commiter on at least two
> such projects, I say spend the time getting maven working.
>
>
>
Re: Maven build
Posted by Daniel Kulp <da...@iona.com>.
Carl,
> I see we have two options:
> 1.) extend the time line
> 2.) Cut the release as using ant as in the vote thread (the key was to
> let Steve get the test refactor to main-line)
....
> I would like to get a show of hands on this point, and if I am correct
> in my assessment we should create the M1 branch with ant create the RC
> and give the team time to get up to speed with maven on mainline for M2
> and continue M2 development. Rajith can then create the branch and a
> signed RC later today that we can all test.
I just want to point out that if a concensus isn't reached and a vote
needs to be called, that will delay M1 for at least another 3 days as the
vote MUST be run for 72 hours. In those 3 days, most of the maven
issues could be fixed.
> Please can you show your level of comfort including maven (release
> maven branch) or ant build for M1 (1 line answers so that we can
> easily see where the committers are at)
I'm -1 (non-binding) to releasing with Ant as that would mean other
projects would not be able to take dependencies on it. (unless someone
spends some time getting the ant build to generate maven artifacts, which
would be a stupid waste of time) Since I'm a commiter on at least two
such projects, I say spend the time getting maven working.
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194 F:781-902-8001
daniel.kulp@iona.com
Re: Maven build
Posted by Steven Shaw <st...@gmail.com>.
+1 Ant for M1, Maven for M2
Re: Maven build
Posted by Martin Ritchie <ri...@apache.org>.
On 14/11/06, Carl Trieloff <cc...@redhat.com> wrote:
> Please can you show your level of comfort including maven (release maven
> branch) or ant build for M1 (1 line answers so that we can
> easily see where the committers are at)
+1 for ant build for M1.
--
Martin Ritchie
Re: Maven build
Posted by Robert Greig <ro...@gmail.com>.
> Please can you show your level of comfort including maven (release maven
> branch) or ant build for M1 (1 line answers so that we can
> easily see where the committers are at)
+1 for ant build for M1.
RG
Re: IRC, IM, etc. (was: Re: Maven build)
Posted by John O'Hara <jo...@gmail.com>.
Some of us can't use that from work.
Network security types have powerful network sniffers, and they do come
calling -- about 5 days to notice last time we tried it for the protocol
working group!
We can, however, use Jabber, AOL and Yahoo IM.... any way of getting Logged
IRC out of that mess?
john
On 14/11/06, Daniel Kulp <da...@iona.com> wrote:
>
>
> > P.S. If there actually is an informal Qpid IRC channel, can someone
> > point me to it? Also, it would be best to put the details on the wiki
> > if they're not already there.
>
> Just FYI: if you want the channel on irc.codehaus.org, we could probably
> get it logged fairly easily. That's what we've done for the #CXF
> channel.
>
> Also, codehaus.org has a "http frontend" at:
> http://irc.codehaus.org/
> so even those behind firewalls can participate.
>
> That said, decisions still must be made on the email list.
>
> --
> J. Daniel Kulp
> Principal Engineer
> IONA
> P: 781-902-8727 C: 508-380-7194 F:781-902-8001
> daniel.kulp@iona.com
>
Re: IRC, IM, etc.
Posted by Carl Trieloff <cc...@redhat.com>.
Someone has created a qpid channel out at freenode.... there is little
-> no traffic on it.
Carl.
Daniel Kulp wrote:
>> P.S. If there actually is an informal Qpid IRC channel, can someone
>> point me to it? Also, it would be best to put the details on the wiki
>> if they're not already there.
>>
>
> Just FYI: if you want the channel on irc.codehaus.org, we could probably
> get it logged fairly easily. That's what we've done for the #CXF
> channel.
>
> Also, codehaus.org has a "http frontend" at:
> http://irc.codehaus.org/
> so even those behind firewalls can participate.
>
> That said, decisions still must be made on the email list.
>
>
Re: IRC, IM, etc. (was: Re: Maven build)
Posted by Daniel Kulp <da...@iona.com>.
> P.S. If there actually is an informal Qpid IRC channel, can someone
> point me to it? Also, it would be best to put the details on the wiki
> if they're not already there.
Just FYI: if you want the channel on irc.codehaus.org, we could probably
get it logged fairly easily. That's what we've done for the #CXF
channel.
Also, codehaus.org has a "http frontend" at:
http://irc.codehaus.org/
so even those behind firewalls can participate.
That said, decisions still must be made on the email list.
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194 F:781-902-8001
daniel.kulp@iona.com
Re: Maven build
Posted by Steve Vinoski <vi...@iona.com>.
On Nov 14, 2006, at 12:01 PM, Carl Trieloff wrote:
> Please can you show your level of comfort including maven (release
> maven branch) or ant build for M1 (1 line answers so that we can
> easily see where the committers are at)
+1 for maven.
--steve
Re: IRC, IM, etc.
Posted by Carl Trieloff <cc...@redhat.com>.
For some reason my posts are getting dropped or delayed. re-send.
Carl Trieloff wrote:
> Steve Vinoski wrote:
>> On Nov 14, 2006, at 12:01 PM, Carl Trieloff wrote:
>>
>>> From informal discussion, IRC, IM etc this morning that I want to
>>> reflect back onto the list some of the informal comments. From
>>> these watercooler discussion it is clear to me that we don't have
>>> anyone with deep maven experience which is creating unease.
>>
>> A point of order: having these offline discussions is not the way
>> things are supposed to happen. Reflecting them back to this list does
>> not make it right. You're having discussions about maven work without
>> inviting anyone with maven knowledge to the table.
> Not true.
>> and then implicitly forcing decisions based on those discussions back
>> onto this list.
> Not true.
>>
>> Please keep important issues like this off IRC, IM, and such, and in
>> this mailing list, so that we can all participate.
>
> ... the key is that no business is conducted or decisions are made off
> the list. however if I walk into you in a pub or speak to someone in a
> cafeteria you can be sure we will talk. For example you and I IM every
> now and again, and you can IRC to the asfinfra team....
>
> To this end, I head some concerns from others, and brought this
> straight back to the list. I hope that you will do the same. Bringing
> items to the list so that we can have an open public list discussion
> is the right way to do it (which is what is current happening on the
> list on the maven topic), and not to pretend that no-one ever speaks
> to anyone else. I wrote a similar mail when I noted your concerns
> about trying to get maven done with all the changes in the tests, to
> check group consensus to merge the test changes directly on main-line,
> and yes you and I IM'ed at bit that morning - the discussion to open a
> window for maven was however discussed on the list.
>
> To expect that someone will not IM/IRC someone they know to ask a
> question is absurd. The key is what you say above: ---> that no
> project decisions are happening off list <--
>
> This is exactly why I wrote the mail I did on the maven topic on the
> list,
>
> regards,
> Carl.
>
>>
>> --steve
>>
>> P.S. If there actually is an informal Qpid IRC channel, can someone
>> point me to it? Also, it would be best to put the details on the wiki
>> if they're not already there.
>
>
Re: IRC, IM, etc.
Posted by Carl Trieloff <cc...@redhat.com>.
Steve Vinoski wrote:
> On Nov 14, 2006, at 12:01 PM, Carl Trieloff wrote:
>
>> From informal discussion, IRC, IM etc this morning that I want to
>> reflect back onto the list some of the informal comments. From these
>> watercooler discussion it is clear to me that we don't have anyone
>> with deep maven experience which is creating unease.
>
> A point of order: having these offline discussions is not the way
> things are supposed to happen. Reflecting them back to this list does
> not make it right. You're having discussions about maven work without
> inviting anyone with maven knowledge to the table.
Not true.
> and then implicitly forcing decisions based on those discussions back
> onto this list.
Not true.
>
> Please keep important issues like this off IRC, IM, and such, and in
> this mailing list, so that we can all participate.
... the key is that no business is conducted or decisions are made off
the list. however if I walk into you in a pub or speak to someone in a
cafeteria you can be sure we will talk. For example you and I IM every
now and again, and you can IRC to the asfinfra team....
To this end, I head some concerns from others, and brought this straight
back to the list. I hope that you will do the same. Bringing items to
the list so that we can have an open public list discussion is the right
way to do it (which is what is current happening on the list on the
maven topic), and not to pretend that no-one ever speaks to anyone
else. I wrote a similar mail when I noted your concerns about trying to
get maven done with all the changes in the tests, to check group
consensus to merge the test changes directly on main-line, and yes you
and I IM'ed at bit that morning - the discussion to open a window for
maven was however discussed on the list.
To expect that someone will not IM/IRC someone they know to ask a
question is absurd. The key is what you say above: ---> that no project
decisions are happening off list <--
This is exactly why I wrote the mail I did on the maven topic on the list,
regards,
Carl.
>
> --steve
>
> P.S. If there actually is an informal Qpid IRC channel, can someone
> point me to it? Also, it would be best to put the details on the wiki
> if they're not already there.
IRC, IM, etc. (was: Re: Maven build)
Posted by Steve Vinoski <vi...@iona.com>.
On Nov 14, 2006, at 12:01 PM, Carl Trieloff wrote:
> From informal discussion, IRC, IM etc this morning that I want to
> reflect back onto the list some of the informal comments. From
> these watercooler discussion it is clear to me that we don't have
> anyone with deep maven experience which is creating unease.
A point of order: having these offline discussions is not the way
things are supposed to happen. Reflecting them back to this list does
not make it right. You're having discussions about maven work without
inviting anyone with maven knowledge to the table, and then
implicitly forcing decisions based on those discussions back onto
this list.
Please keep important issues like this off IRC, IM, and such, and in
this mailing list, so that we can all participate.
--steve
P.S. If there actually is an informal Qpid IRC channel, can someone
point me to it? Also, it would be best to put the details on the wiki
if they're not already there.
Re: Maven build
Posted by Carl Trieloff <cc...@redhat.com>.
Putting M1 together:
Last week I proposed to delay a few days to see if we could bring maven
in, or at least get the test refactor onto to trunk. At this point we
have are beyond the time line set forth in that extend vote thread Friday.
I see we have two options:
1.) extend the time line
2.) Cut the release as using ant as in the vote thread (the key was to
let Steve get the test refactor to main-line)
From informal discussion, IRC, IM etc this morning that I want to
reflect back onto the list some of the informal comments. From these
watercooler discussion it is clear to me that we don't have anyone with
deep maven experience which is creating unease. Hats off to Steve for
the fantastic job he has done, but never less it looks like it might
take a week or more for everyone to get comfortable enough to release M1
with maven. (Not because of the outstanding issues, but knowing that we
have it right)
I would like to get a show of hands on this point, and if I am correct
in my assessment we should create the M1 branch with ant create the RC
and give the team time to get up to speed with maven on mainline for M2
and continue M2 development. Rajith can then create the branch and a
signed RC later today
that we can all test.
Please can you show your level of comfort including maven (release maven
branch) or ant build for M1 (1 line answers so that we can
easily see where the committers are at)
Regards
Carl.
Re: Maven build
Posted by Steve Vinoski <vi...@iona.com>.
On Nov 14, 2006, at 11:43 AM, Robert Greig wrote:
> On 14/11/06, Steve Vinoski <vi...@iona.com> wrote:
>>
>> Who is making these decisions regarding dates and deadlines, and why
>> are they not being communicated to the Qpid community?
>
> Here is the email Carl Trieloff sent out:
>
> http://mail-archives.apache.org/mod_mbox/incubator-qpid-dev/
> 200611.mbox/%3c4554C8C1.2070305@redhat.com%3e
>
>
>> I can't hit deadlines that I don't know about.
>
> And here is your +1 in response:
>
> http://mail-archives.apache.org/mod_mbox/incubator-qpid-dev/
> 200611.mbox/%3cD52C1802-729B-49A9-9B86-583D58FD064D@iona.com%3e
>
> We have already gone well beyond the original agreed timescale of
> Monday.
"Well beyond?" Give me a break.
I agreed to have the tests refactored and maven building and passing
by Monday. I did that. Last night I agreed to have some sort of
distribution working by midnight or 1am, but I missed that by an
hour, as I committed at 2am. Yes, that distribution has minor issues.
All are easily fixed.
I would think some flexibility would be in order here. It's going to
take several weeks to get an M1 officially out. One more day isn't
going to matter much.
--steve
Re: Maven build
Posted by Robert Greig <ro...@gmail.com>.
On 14/11/06, Steve Vinoski <vi...@iona.com> wrote:
>
> Who is making these decisions regarding dates and deadlines, and why
> are they not being communicated to the Qpid community?
Here is the email Carl Trieloff sent out:
http://mail-archives.apache.org/mod_mbox/incubator-qpid-dev/200611.mbox/%3c4554C8C1.2070305@redhat.com%3e
> I can't hit deadlines that I don't know about.
And here is your +1 in response:
http://mail-archives.apache.org/mod_mbox/incubator-qpid-dev/200611.mbox/%3cD52C1802-729B-49A9-9B86-583D58FD064D@iona.com%3e
We have already gone well beyond the original agreed timescale of Monday.
RG
Re: Maven build
Posted by Steve Vinoski <vi...@iona.com>.
On Nov 14, 2006, at 11:19 AM, Martin Ritchie wrote:
> On 14/11/06, Steve Vinoski <vi...@iona.com> wrote:
>> Hi Martin, thanks for the detailed report. I already knew about most
>> of these, but made a decision to finally get some sleep rather than
>> try to fix it all up in the middle of the night. Everything you've
>> listed can and will be fixed relatively easily today.
>
> That would be great but my understanding was that we would branch M1
> this morning so that we could get on with M2 development on the trunk
> and to start the release process. Sorting all the ASF procedures and
> most importantly testing the candidate. I'm a little concerned about
> the precedent we are setting my letting deadlines slip for
> non-functional features.
Who is making these decisions regarding dates and deadlines, and why
are they not being communicated to the Qpid community?
I can't hit deadlines that I don't know about.
I'll respond to the rest of your message in a separate email.
--steve
Re: Maven build
Posted by Martin Ritchie <ri...@apache.org>.
On 14/11/06, Steve Vinoski <vi...@iona.com> wrote:
> Hi Martin, thanks for the detailed report. I already knew about most
> of these, but made a decision to finally get some sleep rather than
> try to fix it all up in the middle of the night. Everything you've
> listed can and will be fixed relatively easily today.
That would be great but my understanding was that we would branch M1
this morning so that we could get on with M2 development on the trunk
and to start the release process. Sorting all the ASF procedures and
most importantly testing the candidate. I'm a little concerned about
the precedent we are setting my letting deadlines slip for
non-functional features.
> On Nov 14, 2006, at 8:41 AM, Martin Ritchie wrote:
>
> > Qpid-developers,
> > There are still a few issues I've noted with using the mvn branch for
> > M1. Most of the issues are quite small but we need to start testing
> > and working on the rest of the release process without holding up M2
> > development.
> >
> > Build:
> > - Mina jar is downloaded rather than using our existing snapshot.
>
> Yes, and this is a good thing. If it works with a build provided by
> the team, that's much better than us having to grab a particular svn
> revision off the mina svn repository and build it for ourselves.
Our releases should not have to coincide with Mina snapshots. We moved
to 1.1 as 1.0.0 had some outstanding bugs. The api changes that
occurred a few weeks ago have broken our builds against MINA-head but
we should still be able to release with the jars we built.
Incidentally I have the changes that restores compatibility with
MINA-head but I was believed we were on a code freeze prior to M1.
> > Both Distributions
> > - Top level License file doesn't reference or include all other
> > license files.
> > - Disclaimer content is wrong. (currently for CXF)
>
> Yes, I hadn't gotten to the license stuff yet. It's easily included,
> and the disclaimer is easily fixed.
>
> > Source Distribution
> > - AMQP Specification is not included so compilation cannot occur, see
> > mvn output at end of email.
>
> This is partly due to the nature of the branch, as it's only a copy
> of everything from the java level and below. Adding it is, again, easy.
>
> > - Should the source include sufficient files to be able to do a
> > release? or should it just be the project source files for
> > compilation.
>
> I don't know the answer to that.
>
> > Binary Distribution
> > - Windows batch scripts no longer work as the <module>-launcher.jars
> > are not generated.
>
> Rather than generating separate client and broker launcher jars,
> there's one qpid-incubator.jar. The broker/etc/qpid-server.conf file
> reflects the use of that jar, for example, and Windows scripts are
> easily fixed. Perhaps this goes against the desire to allow clients
> to be JDK 1.4, but as I mentioned in earlier emails, the client tests
> use junit4 annotations and thus can't be compiled with 1.4 anyway,
> which means that with maven that whole directory must be built with
> 1.5. The 1.4 thing is a red herring IMO.
>
> Also, I don't think that those launcher jars can be named that way,
> by Apache rules. I believe the term "incubator" or "incubating" has
> to appear in there somewhere.
The launcher jars are purely meta jars and so shouldn't require the
META-INF directory nor the naming convention associated with the build
jars.
> > - META-INF directory in generated jars are missing
> > Disclaimer,License and Notes
>
> Easily fixed.
>
> > - No JavaDoc in the doc folder
>
> How useful is the javadoc? I started to add it but left it out for
> now, since is provides no clear delineation of what is interface and
> what is implementation. Simply javadoc'ing every class in the system
> isn't that useful, IMO.
>
> If you look at Tuscany, CXF, or Yoko, they build an API jar that
> reflects the actual application interface, and generate javadoc from
> that. I believe we should take a similar approach.
In which case we need a JIRA for that but to ship an M1 with no
documentation seems rather poor.
> > - Management module is missing
>
> As is cluster -- I explicitly left them out, in the interest of
> getting something to show in time. Adding them requires 3 more lines
> in the pom and just a few lines in the assembly specifications.
>
> > Other issues
> > - Library naming, how do we do a Release rather than a snapshot?
>
> By changing pom version numbers.
>
> > - Should we include an empty log directory in the binary build?
> >
> > I know Steve has put a LOT of good work into getting maven
> > together. My
> > understanding of the M1 release was so we had baseline to support our
> > current clients.
>
> The big white elephant in the room here is that some here seem to
> want M1 to be a release of the ant-based status quo, while others
> want M1 to include maven for a variety of reasons, not the least of
> which is that it we believe it's the right way forward for the Qpid
> development community, represents how we think releases ought to be
> done, shows that we're quickly and properly learning Apache
> guidelines and practices, and avoids doing the same work two or more
> times, first in ant then in maven.
>
> If an existing client takes a binary release created with maven, to
> the best of my knowledge, the only thing that changes is the name of
> the "launcher" jar, which as I explained above has to be renamed
> anyway. So what else is it about the maven release that you think
> won't support existing clients?
You misunderstand me, I would just like to agree on ANY release as we
need to do testing and verification that the release adheres to ASF
guidelines and it would be good to work on that in parallel with M2
features.
> > Is there any other issues that anyone else has noticed?
>
> We still have the junit3 vs. junit4 issue, which we should answer ASAP.
>
> --steve
>
> >
> > --
> > Martin
> >
> >
> > Here is the error I get trying to do a mvn from the source release:
> > [INFO] Scanning for projects...
> > [INFO] Reactor build order:
> > [INFO] Qpid
> > [INFO] Qpid Common Utilities
> > [INFO] Qpid Broker
> > [INFO] Qpid Client
> > [INFO] Qpid Management
> > [INFO] Qpid Management Core
> > [INFO] Qpid Management Client
> > [INFO] Qpid Cluster
> > [INFO] Qpid System Tests
> > [INFO]
> > ----------------------------------------------------------------------
> > ------
> > [INFO] Building Qpid
> >
> > [INFO] task-segment: [install]
> > [INFO]
> > ----------------------------------------------------------------------
> > ------
> >
> > [INFO] [site:attach-descriptor]
> > [INFO] [install:install]
> > [INFO] Installing c:\dev\Apache
> > Projects\Qpid-Head\Qpid\branches\mvn\distribution\target\qpid-1.0-in
> > cubator-M1-SNAPSHOT-java-src\qpid-1.0-incubator-M1-SNAPSHOT-src
> > \pom.xml
> > to c:\.mvn\repository\org\ap
> > ache\qpid\qpid\1.0-incubator-M1-SNAPSHOT\qpid-1.0-incubator-M1-
> > SNAPSHOT.pom
> > [INFO]
> > ----------------------------------------------------------------------
> > ------
> > [INFO] Building Qpid Common Utilities
> >
> > [INFO] task-segment: [install]
> > [INFO]
> > ----------------------------------------------------------------------
> > ------
> >
> > [INFO] [antrun:run {execution: protocol-version}]
> > [INFO] Executing tasks
> >
> > generate:
> > [mkdir] Created dir: C:\dev\Apache
> > Projects\Qpid-Head\Qpid\branches\mvn\distribution\target\qpid
> > -1.0-incubator-M1-SNAPSHOT-java-src\qpid-1.0-incubator-M1-SNAPSHOT-
> > src\common\target\generated\xsl\o
> > rg\apache\qpid\framing
> > [copy] Copying 1 file to C:\dev\Apache
> > Projects\Qpid-Head\Qpid\branches\mvn\distribution\target
> > \qpid-1.0-incubator-M1-SNAPSHOT-java-src\qpid-1.0-incubator-M1-
> > SNAPSHOT-src\common\target\generated\
> > xsl\org\apache\qpid\framing
> >
> > [INFO]
> > ----------------------------------------------------------------------
> > --
> > [ERROR] BUILD ERROR
> > [INFO]
> > ----------------------------------------------------------------------
> > --
> >
> > [INFO] Error executing ant tasks
> >
> > Embedded error: The following error occurred while executing this
> > line:
> > C:\dev\Apache Projects\Qpid-Head\Qpid\branches\mvn\distribution
> > \target\qpid-1.0-incubator-M1-SNAPSHO
> > T-java-src\qpid-1.0-incubator-M1-SNAPSHOT-src\common\protocol-
> > version.xml:106:
> > The following error o
> > ccurred while executing this line:
> > C:\dev\Apache Projects\Qpid-Head\Qpid\branches\mvn\distribution
> > \target\qpid-1.0-incubator-M1-SNAPSHO
> > T-java-src\qpid-1.0-incubator-M1-SNAPSHOT-src\common\protocol-
> > version.xml:49:
> > ERROR: AMQP specificat
> > ion file ../../../trunk/qpid/specs/amqp-8.0.xml not found.
> > [INFO]
> > ----------------------------------------------------------------------
> > --
> > [INFO] For more information, run Maven with the -e switch
> > [INFO]
> > ----------------------------------------------------------------------
> > --
> > [INFO] Total time: 3 seconds
> > [INFO] Finished at: Tue Nov 14 08:40:19 GMT 2006
> > [INFO] Final Memory: 7M/14M
> > [INFO]
> > ----------------------------------------------------------------------
> > --
> >
> >
> >
> > On 14/11/06, Martin Ritchie <ri...@apache.org> wrote:
> >> There are still a few problems with the mvn distribution:
> >>
> >> Both Distributions
> >> -Top level License file doesn't reference or include all other
> >> license files.
> >>
> >> Source Distribution
> >> - AMQP Specification is not included so compilation cannot occur, see
> >> mvn output at end of email.
> >> - Should the source include sufficient files to be able to do a
> >> release? Should it not just be the project source files for
> >> compilation.
> >>
> >> Binary Distribution
> >> - Windows batch scripts no longer work as the <module>-launcher.jars
> >> are not generated.
> >> - META-INF directory is missing Disclaimer,License and Notes
> >> - Library naming, how do we do a Release rather than a snapshot?
> >>
> >> There is quite a list of things that need to be resolved. I know
> >> Steve
> >> has put a LOT of good work into getting maven together. My
> >> understanding of the M1 release was so we had baseline to support our
> >> current clients.
> >>
> >> Given that our current schedule is to do a M2 before Christmas
> >> what is
> >> the groups view?
> >>
> >> [ ] Branch now for M1
> >> [ ] Fix outstanding maven issues for M2 which is around 4 weeks
> >> from now.
> >>
> >> --
> >> Martin
> >>
> >>
> >> Here is the error I get trying to do a mvn from the source release:
> >> [INFO] Scanning for projects...
> >> [INFO] Reactor build order:
> >> [INFO] Qpid
> >> [INFO] Qpid Common Utilities
> >> [INFO] Qpid Broker
> >> [INFO] Qpid Client
> >> [INFO] Qpid Management
> >> [INFO] Qpid Management Core
> >> [INFO] Qpid Management Client
> >> [INFO] Qpid Cluster
> >> [INFO] Qpid System Tests
> >> [INFO]
> >> ---------------------------------------------------------------------
> >> -------
> >> [INFO] Building Qpid
> >> [INFO] task-segment: [install]
> >> [INFO]
> >> ---------------------------------------------------------------------
> >> -------
> >> [INFO] [site:attach-descriptor]
> >> [INFO] [install:install]
> >> [INFO] Installing c:\dev\Apache
> >> Projects\Qpid-Head\Qpid\branches\mvn\distribution\target\qpid-1.0-in
> >> cubator-M1-SNAPSHOT-java-src\qpid-1.0-incubator-M1-SNAPSHOT-src
> >> \pom.xml
> >> to c:\.mvn\repository\org\ap
> >> ache\qpid\qpid\1.0-incubator-M1-SNAPSHOT\qpid-1.0-incubator-M1-
> >> SNAPSHOT.pom
> >> [INFO]
> >> ---------------------------------------------------------------------
> >> -------
> >> [INFO] Building Qpid Common Utilities
> >> [INFO] task-segment: [install]
> >> [INFO]
> >> ---------------------------------------------------------------------
> >> -------
> >> [INFO] [antrun:run {execution: protocol-version}]
> >> [INFO] Executing tasks
> >>
> >> generate:
> >> [mkdir] Created dir: C:\dev\Apache
> >> Projects\Qpid-Head\Qpid\branches\mvn\distribution\target\qpid
> >> -1.0-incubator-M1-SNAPSHOT-java-src\qpid-1.0-incubator-M1-SNAPSHOT-
> >> src\common\target\generated\xsl\o
> >> rg\apache\qpid\framing
> >> [copy] Copying 1 file to C:\dev\Apache
> >> Projects\Qpid-Head\Qpid\branches\mvn\distribution\target
> >> \qpid-1.0-incubator-M1-SNAPSHOT-java-src\qpid-1.0-incubator-M1-
> >> SNAPSHOT-src\common\target\generated\
> >> xsl\org\apache\qpid\framing
> >> [INFO]
> >> ---------------------------------------------------------------------
> >> ---
> >> [ERROR] BUILD ERROR
> >> [INFO]
> >> ---------------------------------------------------------------------
> >> ---
> >> [INFO] Error executing ant tasks
> >>
> >> Embedded error: The following error occurred while executing this
> >> line:
> >> C:\dev\Apache Projects\Qpid-Head\Qpid\branches\mvn\distribution
> >> \target\qpid-1.0-incubator-M1-SNAPSHO
> >> T-java-src\qpid-1.0-incubator-M1-SNAPSHOT-src\common\protocol-
> >> version.xml:106:
> >> The following error o
> >> ccurred while executing this line:
> >> C:\dev\Apache Projects\Qpid-Head\Qpid\branches\mvn\distribution
> >> \target\qpid-1.0-incubator-M1-SNAPSHO
> >> T-java-src\qpid-1.0-incubator-M1-SNAPSHOT-src\common\protocol-
> >> version.xml:49:
> >> ERROR: AMQP specificat
> >> ion file ../../../trunk/qpid/specs/amqp-8.0.xml not found.
> >> [INFO]
> >> ---------------------------------------------------------------------
> >> ---
> >> [INFO] For more information, run Maven with the -e switch
> >> [INFO]
> >> ---------------------------------------------------------------------
> >> ---
> >> [INFO] Total time: 3 seconds
> >> [INFO] Finished at: Tue Nov 14 08:40:19 GMT 2006
> >> [INFO] Final Memory: 7M/14M
> >> [INFO]
> >> ---------------------------------------------------------------------
> >> ---
> >>
> >> On 14/11/06, Robert Greig <ro...@gmail.com> wrote:
> >> > On 13/11/06, Daniel Kulp <da...@iona.com> wrote:
> >> > > > > Hi Martin, that's odd, since mina 1.0.0 exists under the
> >> central
> >> > > > > repository at http://repo1.maven.org/maven2:
> >> > > > >
> >> > > > > <http://repo1.maven.org/maven2/org/apache/mina/>
> >> > > > >
> >> > > > > Maybe you just hit a network glitch or something like that?
> >> > > >
> >> > > > I am seeing exactly the same problem - have tried a few
> >> times. Is
> >> > > > there any special configuration required?
> >> >
> >> > The problem was this:
> >> >
> >> > "Maven 2.0.4 and lower, doesn't support https and proxy so if
> >> you're
> >> > in that case (and you're in that case if you're behind a proxy
> >> because
> >> > java.net website uses https protocol) there is still a
> >> workaround; use
> >> > the following system properties when using maven :
> >> >
> >> > -Dhttps.proxyHost=[proxy] -Dhttps.proxyPort=[port]"
> >> >
> >> > This was resolved when the order was changed in the POM.
> >> >
> >> > RG
> >> >
> >>
> >>
> >> --
> >> Martin Ritchie
> >>
> >
> >
> > --
> > Martin Ritchie
>
>
--
Martin Ritchie
Re: Maven build
Posted by Bhupendra Bhardwaj <bh...@gmail.com>.
Hi,
I think we should use ant for M1. M2 is not too far to go with Maven.
+1 for ant build for M1.
Regards,
Bhupendra Bhardwaj
On 11/14/06, Robert Greig <ro...@gmail.com> wrote:
>
> On 14/11/06, Steve Vinoski <vi...@iona.com> wrote:
> >
> > Don't put words in my mouth, Robert.
>
> I don't think I need to; you seem to have plenty already.
>
> > Nowhere do I say that Apache
> > guidelines require maven. I was saying that releases in the incubator
> > are intended to show that the project has a viable and diverse
> > community, and that that community knows the rules and regulations
> > required for releases.
>
> And in the context of your email I read that as implying that maven
> was part of that. Maybe that was a misinterpretation but it certainly
> read like that to me.
>
> > I didn't say it was a barrier. I said, and have been saying for
> > weeks, that doing the work twice, once in ant and again in maven, is
> > pointless.
>
> We are talking about a very small amount of modification to the ant
> build system in order to get a release out there. It is the maven work
> that seems to have been weeks of effort.
>
> RG
>
Re: Maven build
Posted by Robert Greig <ro...@gmail.com>.
> I worked on Sunday to get the initial mvn branch in. I then worked
> again last night to do the distribution stuff, which was a separate
> request.
Then there clearly has been another communication breakdown since that
was not my expectation or that of at least some others.
RG
Re: Maven build
Posted by Steve Vinoski <vi...@iona.com>.
On Nov 14, 2006, at 1:12 PM, Robert Greig wrote:
> On 14/11/06, Steve Vinoski <vi...@iona.com> wrote:
>
>> > And in the context of your email I read that as implying that maven
>> > was part of that. Maybe that was a misinterpretation but it
>> certainly
>> > read like that to me.
>>
>> Saying that "maven is required" would clearly be provably wrong,
>> wouldn't it? So why would you think that that's what I'm saying?
>
> I have no idea what you believe or don't believe, I can only interpret
> based on what you write.
Precisely. So since you can't show me where I explicitly said that
maven is required, please stop sending these pointless emails.
>> Actually, no. It was mere days of effort. I was traveling for several
>> weeks in the middle of that work, and once I got back into the work,
>> I ran into the issue of the poorly-structured tests. I tried multiple
>> avenues around the test issues and around the junit4 issues, which
>> took a few days, but once I refactored the tests, the new mvn branch
>> took just a few hours on Sunday to put together.
>
> But you stated in an earlier email that you were working until 2am
> yesterday on it? Or am I putting words in your mouth again?
It's unfortunate, Robert, that you can't seem to act as an adult
here. This will therefore be my last email on this, as this thread is
not helping the Qpid community.
I worked on Sunday to get the initial mvn branch in. I then worked
again last night to do the distribution stuff, which was a separate
request.
--steve
Re: Maven build
Posted by Robert Greig <ro...@gmail.com>.
On 14/11/06, Steve Vinoski <vi...@iona.com> wrote:
> > And in the context of your email I read that as implying that maven
> > was part of that. Maybe that was a misinterpretation but it certainly
> > read like that to me.
>
> Saying that "maven is required" would clearly be provably wrong,
> wouldn't it? So why would you think that that's what I'm saying?
I have no idea what you believe or don't believe, I can only interpret
based on what you write.
> Actually, no. It was mere days of effort. I was traveling for several
> weeks in the middle of that work, and once I got back into the work,
> I ran into the issue of the poorly-structured tests. I tried multiple
> avenues around the test issues and around the junit4 issues, which
> took a few days, but once I refactored the tests, the new mvn branch
> took just a few hours on Sunday to put together.
But you stated in an earlier email that you were working until 2am
yesterday on it? Or am I putting words in your mouth again?
RG
Re: Maven build
Posted by Steve Vinoski <vi...@iona.com>.
On Nov 14, 2006, at 12:52 PM, Robert Greig wrote:
> On 14/11/06, Steve Vinoski <vi...@iona.com> wrote:
>>
>> Don't put words in my mouth, Robert.
>
> I don't think I need to; you seem to have plenty already.
Personal insults are neither helpful nor required here.
>> Nowhere do I say that Apache
>> guidelines require maven. I was saying that releases in the incubator
>> are intended to show that the project has a viable and diverse
>> community, and that that community knows the rules and regulations
>> required for releases.
>
> And in the context of your email I read that as implying that maven
> was part of that. Maybe that was a misinterpretation but it certainly
> read like that to me.
Saying that "maven is required" would clearly be provably wrong,
wouldn't it? So why would you think that that's what I'm saying?
>> I didn't say it was a barrier. I said, and have been saying for
>> weeks, that doing the work twice, once in ant and again in maven, is
>> pointless.
>
> We are talking about a very small amount of modification to the ant
> build system in order to get a release out there. It is the maven work
> that seems to have been weeks of effort.
Actually, no. It was mere days of effort. I was traveling for several
weeks in the middle of that work, and once I got back into the work,
I ran into the issue of the poorly-structured tests. I tried multiple
avenues around the test issues and around the junit4 issues, which
took a few days, but once I refactored the tests, the new mvn branch
took just a few hours on Sunday to put together.
--steve
Re: Maven build
Posted by Robert Greig <ro...@gmail.com>.
On 14/11/06, Steve Vinoski <vi...@iona.com> wrote:
>
> Don't put words in my mouth, Robert.
I don't think I need to; you seem to have plenty already.
> Nowhere do I say that Apache
> guidelines require maven. I was saying that releases in the incubator
> are intended to show that the project has a viable and diverse
> community, and that that community knows the rules and regulations
> required for releases.
And in the context of your email I read that as implying that maven
was part of that. Maybe that was a misinterpretation but it certainly
read like that to me.
> I didn't say it was a barrier. I said, and have been saying for
> weeks, that doing the work twice, once in ant and again in maven, is
> pointless.
We are talking about a very small amount of modification to the ant
build system in order to get a release out there. It is the maven work
that seems to have been weeks of effort.
RG
Re: Maven build
Posted by Steve Vinoski <vi...@iona.com>.
On Nov 14, 2006, at 12:01 PM, Robert Greig wrote:
>> which is that it we believe it's the right way forward for the Qpid
>> development community, represents how we think releases ought to be
>> done, shows that we're quickly and properly learning Apache
>> guidelines and practices
>
> I am not sure where "properly learning Apache guidlines and practices"
> has started meaning use maven but do let me know if I missed a
> document.
Don't put words in my mouth, Robert. Nowhere do I say that Apache
guidelines require maven. I was saying that releases in the incubator
are intended to show that the project has a viable and diverse
community, and that that community knows the rules and regulations
required for releases.
> I note with interest that the OFBiz project graduated today from the
> incubator and it uses ant for its build system, so it does not seem to
> be a major barrier.
>
> http://mail-archives.apache.org/mod_mbox/incubator-ofbiz-dev/
> 200611.mbox/%3cD567AD41-94FD-432B-B2BC-
> DC10F36A193A@undersunconsulting.com%3e
I didn't say it was a barrier. I said, and have been saying for
weeks, that doing the work twice, once in ant and again in maven, is
pointless.
Perhaps you should start actually reading what my emails say, rather
than trying to make them say what you want to hear.
--steve
Re: Maven build
Posted by Robert Greig <ro...@gmail.com>.
> which is that it we believe it's the right way forward for the Qpid
> development community, represents how we think releases ought to be
> done, shows that we're quickly and properly learning Apache
> guidelines and practices
I am not sure where "properly learning Apache guidlines and practices"
has started meaning use maven but do let me know if I missed a
document.
I note with interest that the OFBiz project graduated today from the
incubator and it uses ant for its build system, so it does not seem to
be a major barrier.
http://mail-archives.apache.org/mod_mbox/incubator-ofbiz-dev/200611.mbox/%3cD567AD41-94FD-432B-B2BC-DC10F36A193A@undersunconsulting.com%3e
RG
Re: Maven build
Posted by Steve Vinoski <vi...@iona.com>.
On Nov 14, 2006, at 11:51 AM, Robert Greig wrote:
> On 14/11/06, Steve Vinoski <vi...@iona.com> wrote:
>
>> The big white elephant in the room here is that some here seem to
>> want M1 to be a release of the ant-based status quo, while others
>> want M1 to include maven for a variety of reasons, not the least of
>> which is that it we believe it's the right way forward for the Qpid
>> development community, represents how we think releases ought to be
>> done, shows that we're quickly and properly learning Apache
>> guidelines and practices, and avoids doing the same work two or more
>> times, first in ant then in maven.
>
> The funamental point is that whether it is built with ant or maven
> matters not one jot to our users. We would like to get M1 released so
> that we can move on and start focussing on adding functionality for
> M2.
I beg to differ. Other projects will want to start integrating with
Qpid, and maven makes that much easier to do.
--steve
Re: Maven build
Posted by Robert Greig <ro...@gmail.com>.
On 14/11/06, Steve Vinoski <vi...@iona.com> wrote:
> The big white elephant in the room here is that some here seem to
> want M1 to be a release of the ant-based status quo, while others
> want M1 to include maven for a variety of reasons, not the least of
> which is that it we believe it's the right way forward for the Qpid
> development community, represents how we think releases ought to be
> done, shows that we're quickly and properly learning Apache
> guidelines and practices, and avoids doing the same work two or more
> times, first in ant then in maven.
The funamental point is that whether it is built with ant or maven
matters not one jot to our users. We would like to get M1 released so
that we can move on and start focussing on adding functionality for
M2.
No one is debating whether we should move to maven it is only an issue
of timing.
RG
Re: Maven build
Posted by Steve Vinoski <vi...@iona.com>.
Hi Martin, thanks for the detailed report. I already knew about most
of these, but made a decision to finally get some sleep rather than
try to fix it all up in the middle of the night. Everything you've
listed can and will be fixed relatively easily today.
On Nov 14, 2006, at 8:41 AM, Martin Ritchie wrote:
> Qpid-developers,
> There are still a few issues I've noted with using the mvn branch for
> M1. Most of the issues are quite small but we need to start testing
> and working on the rest of the release process without holding up M2
> development.
>
> Build:
> - Mina jar is downloaded rather than using our existing snapshot.
Yes, and this is a good thing. If it works with a build provided by
the team, that's much better than us having to grab a particular svn
revision off the mina svn repository and build it for ourselves.
> Both Distributions
> - Top level License file doesn't reference or include all other
> license files.
> - Disclaimer content is wrong. (currently for CXF)
Yes, I hadn't gotten to the license stuff yet. It's easily included,
and the disclaimer is easily fixed.
> Source Distribution
> - AMQP Specification is not included so compilation cannot occur, see
> mvn output at end of email.
This is partly due to the nature of the branch, as it's only a copy
of everything from the java level and below. Adding it is, again, easy.
> - Should the source include sufficient files to be able to do a
> release? or should it just be the project source files for
> compilation.
I don't know the answer to that.
> Binary Distribution
> - Windows batch scripts no longer work as the <module>-launcher.jars
> are not generated.
Rather than generating separate client and broker launcher jars,
there's one qpid-incubator.jar. The broker/etc/qpid-server.conf file
reflects the use of that jar, for example, and Windows scripts are
easily fixed. Perhaps this goes against the desire to allow clients
to be JDK 1.4, but as I mentioned in earlier emails, the client tests
use junit4 annotations and thus can't be compiled with 1.4 anyway,
which means that with maven that whole directory must be built with
1.5. The 1.4 thing is a red herring IMO.
Also, I don't think that those launcher jars can be named that way,
by Apache rules. I believe the term "incubator" or "incubating" has
to appear in there somewhere.
> - META-INF directory in generated jars are missing
> Disclaimer,License and Notes
Easily fixed.
> - No JavaDoc in the doc folder
How useful is the javadoc? I started to add it but left it out for
now, since is provides no clear delineation of what is interface and
what is implementation. Simply javadoc'ing every class in the system
isn't that useful, IMO.
If you look at Tuscany, CXF, or Yoko, they build an API jar that
reflects the actual application interface, and generate javadoc from
that. I believe we should take a similar approach.
> - Management module is missing
As is cluster -- I explicitly left them out, in the interest of
getting something to show in time. Adding them requires 3 more lines
in the pom and just a few lines in the assembly specifications.
> Other issues
> - Library naming, how do we do a Release rather than a snapshot?
By changing pom version numbers.
> - Should we include an empty log directory in the binary build?
>
> I know Steve has put a LOT of good work into getting maven
> together. My
> understanding of the M1 release was so we had baseline to support our
> current clients.
The big white elephant in the room here is that some here seem to
want M1 to be a release of the ant-based status quo, while others
want M1 to include maven for a variety of reasons, not the least of
which is that it we believe it's the right way forward for the Qpid
development community, represents how we think releases ought to be
done, shows that we're quickly and properly learning Apache
guidelines and practices, and avoids doing the same work two or more
times, first in ant then in maven.
If an existing client takes a binary release created with maven, to
the best of my knowledge, the only thing that changes is the name of
the "launcher" jar, which as I explained above has to be renamed
anyway. So what else is it about the maven release that you think
won't support existing clients?
> Is there any other issues that anyone else has noticed?
We still have the junit3 vs. junit4 issue, which we should answer ASAP.
--steve
>
> --
> Martin
>
>
> Here is the error I get trying to do a mvn from the source release:
> [INFO] Scanning for projects...
> [INFO] Reactor build order:
> [INFO] Qpid
> [INFO] Qpid Common Utilities
> [INFO] Qpid Broker
> [INFO] Qpid Client
> [INFO] Qpid Management
> [INFO] Qpid Management Core
> [INFO] Qpid Management Client
> [INFO] Qpid Cluster
> [INFO] Qpid System Tests
> [INFO]
> ----------------------------------------------------------------------
> ------
> [INFO] Building Qpid
>
> [INFO] task-segment: [install]
> [INFO]
> ----------------------------------------------------------------------
> ------
>
> [INFO] [site:attach-descriptor]
> [INFO] [install:install]
> [INFO] Installing c:\dev\Apache
> Projects\Qpid-Head\Qpid\branches\mvn\distribution\target\qpid-1.0-in
> cubator-M1-SNAPSHOT-java-src\qpid-1.0-incubator-M1-SNAPSHOT-src
> \pom.xml
> to c:\.mvn\repository\org\ap
> ache\qpid\qpid\1.0-incubator-M1-SNAPSHOT\qpid-1.0-incubator-M1-
> SNAPSHOT.pom
> [INFO]
> ----------------------------------------------------------------------
> ------
> [INFO] Building Qpid Common Utilities
>
> [INFO] task-segment: [install]
> [INFO]
> ----------------------------------------------------------------------
> ------
>
> [INFO] [antrun:run {execution: protocol-version}]
> [INFO] Executing tasks
>
> generate:
> [mkdir] Created dir: C:\dev\Apache
> Projects\Qpid-Head\Qpid\branches\mvn\distribution\target\qpid
> -1.0-incubator-M1-SNAPSHOT-java-src\qpid-1.0-incubator-M1-SNAPSHOT-
> src\common\target\generated\xsl\o
> rg\apache\qpid\framing
> [copy] Copying 1 file to C:\dev\Apache
> Projects\Qpid-Head\Qpid\branches\mvn\distribution\target
> \qpid-1.0-incubator-M1-SNAPSHOT-java-src\qpid-1.0-incubator-M1-
> SNAPSHOT-src\common\target\generated\
> xsl\org\apache\qpid\framing
>
> [INFO]
> ----------------------------------------------------------------------
> --
> [ERROR] BUILD ERROR
> [INFO]
> ----------------------------------------------------------------------
> --
>
> [INFO] Error executing ant tasks
>
> Embedded error: The following error occurred while executing this
> line:
> C:\dev\Apache Projects\Qpid-Head\Qpid\branches\mvn\distribution
> \target\qpid-1.0-incubator-M1-SNAPSHO
> T-java-src\qpid-1.0-incubator-M1-SNAPSHOT-src\common\protocol-
> version.xml:106:
> The following error o
> ccurred while executing this line:
> C:\dev\Apache Projects\Qpid-Head\Qpid\branches\mvn\distribution
> \target\qpid-1.0-incubator-M1-SNAPSHO
> T-java-src\qpid-1.0-incubator-M1-SNAPSHOT-src\common\protocol-
> version.xml:49:
> ERROR: AMQP specificat
> ion file ../../../trunk/qpid/specs/amqp-8.0.xml not found.
> [INFO]
> ----------------------------------------------------------------------
> --
> [INFO] For more information, run Maven with the -e switch
> [INFO]
> ----------------------------------------------------------------------
> --
> [INFO] Total time: 3 seconds
> [INFO] Finished at: Tue Nov 14 08:40:19 GMT 2006
> [INFO] Final Memory: 7M/14M
> [INFO]
> ----------------------------------------------------------------------
> --
>
>
>
> On 14/11/06, Martin Ritchie <ri...@apache.org> wrote:
>> There are still a few problems with the mvn distribution:
>>
>> Both Distributions
>> -Top level License file doesn't reference or include all other
>> license files.
>>
>> Source Distribution
>> - AMQP Specification is not included so compilation cannot occur, see
>> mvn output at end of email.
>> - Should the source include sufficient files to be able to do a
>> release? Should it not just be the project source files for
>> compilation.
>>
>> Binary Distribution
>> - Windows batch scripts no longer work as the <module>-launcher.jars
>> are not generated.
>> - META-INF directory is missing Disclaimer,License and Notes
>> - Library naming, how do we do a Release rather than a snapshot?
>>
>> There is quite a list of things that need to be resolved. I know
>> Steve
>> has put a LOT of good work into getting maven together. My
>> understanding of the M1 release was so we had baseline to support our
>> current clients.
>>
>> Given that our current schedule is to do a M2 before Christmas
>> what is
>> the groups view?
>>
>> [ ] Branch now for M1
>> [ ] Fix outstanding maven issues for M2 which is around 4 weeks
>> from now.
>>
>> --
>> Martin
>>
>>
>> Here is the error I get trying to do a mvn from the source release:
>> [INFO] Scanning for projects...
>> [INFO] Reactor build order:
>> [INFO] Qpid
>> [INFO] Qpid Common Utilities
>> [INFO] Qpid Broker
>> [INFO] Qpid Client
>> [INFO] Qpid Management
>> [INFO] Qpid Management Core
>> [INFO] Qpid Management Client
>> [INFO] Qpid Cluster
>> [INFO] Qpid System Tests
>> [INFO]
>> ---------------------------------------------------------------------
>> -------
>> [INFO] Building Qpid
>> [INFO] task-segment: [install]
>> [INFO]
>> ---------------------------------------------------------------------
>> -------
>> [INFO] [site:attach-descriptor]
>> [INFO] [install:install]
>> [INFO] Installing c:\dev\Apache
>> Projects\Qpid-Head\Qpid\branches\mvn\distribution\target\qpid-1.0-in
>> cubator-M1-SNAPSHOT-java-src\qpid-1.0-incubator-M1-SNAPSHOT-src
>> \pom.xml
>> to c:\.mvn\repository\org\ap
>> ache\qpid\qpid\1.0-incubator-M1-SNAPSHOT\qpid-1.0-incubator-M1-
>> SNAPSHOT.pom
>> [INFO]
>> ---------------------------------------------------------------------
>> -------
>> [INFO] Building Qpid Common Utilities
>> [INFO] task-segment: [install]
>> [INFO]
>> ---------------------------------------------------------------------
>> -------
>> [INFO] [antrun:run {execution: protocol-version}]
>> [INFO] Executing tasks
>>
>> generate:
>> [mkdir] Created dir: C:\dev\Apache
>> Projects\Qpid-Head\Qpid\branches\mvn\distribution\target\qpid
>> -1.0-incubator-M1-SNAPSHOT-java-src\qpid-1.0-incubator-M1-SNAPSHOT-
>> src\common\target\generated\xsl\o
>> rg\apache\qpid\framing
>> [copy] Copying 1 file to C:\dev\Apache
>> Projects\Qpid-Head\Qpid\branches\mvn\distribution\target
>> \qpid-1.0-incubator-M1-SNAPSHOT-java-src\qpid-1.0-incubator-M1-
>> SNAPSHOT-src\common\target\generated\
>> xsl\org\apache\qpid\framing
>> [INFO]
>> ---------------------------------------------------------------------
>> ---
>> [ERROR] BUILD ERROR
>> [INFO]
>> ---------------------------------------------------------------------
>> ---
>> [INFO] Error executing ant tasks
>>
>> Embedded error: The following error occurred while executing this
>> line:
>> C:\dev\Apache Projects\Qpid-Head\Qpid\branches\mvn\distribution
>> \target\qpid-1.0-incubator-M1-SNAPSHO
>> T-java-src\qpid-1.0-incubator-M1-SNAPSHOT-src\common\protocol-
>> version.xml:106:
>> The following error o
>> ccurred while executing this line:
>> C:\dev\Apache Projects\Qpid-Head\Qpid\branches\mvn\distribution
>> \target\qpid-1.0-incubator-M1-SNAPSHO
>> T-java-src\qpid-1.0-incubator-M1-SNAPSHOT-src\common\protocol-
>> version.xml:49:
>> ERROR: AMQP specificat
>> ion file ../../../trunk/qpid/specs/amqp-8.0.xml not found.
>> [INFO]
>> ---------------------------------------------------------------------
>> ---
>> [INFO] For more information, run Maven with the -e switch
>> [INFO]
>> ---------------------------------------------------------------------
>> ---
>> [INFO] Total time: 3 seconds
>> [INFO] Finished at: Tue Nov 14 08:40:19 GMT 2006
>> [INFO] Final Memory: 7M/14M
>> [INFO]
>> ---------------------------------------------------------------------
>> ---
>>
>> On 14/11/06, Robert Greig <ro...@gmail.com> wrote:
>> > On 13/11/06, Daniel Kulp <da...@iona.com> wrote:
>> > > > > Hi Martin, that's odd, since mina 1.0.0 exists under the
>> central
>> > > > > repository at http://repo1.maven.org/maven2:
>> > > > >
>> > > > > <http://repo1.maven.org/maven2/org/apache/mina/>
>> > > > >
>> > > > > Maybe you just hit a network glitch or something like that?
>> > > >
>> > > > I am seeing exactly the same problem - have tried a few
>> times. Is
>> > > > there any special configuration required?
>> >
>> > The problem was this:
>> >
>> > "Maven 2.0.4 and lower, doesn't support https and proxy so if
>> you're
>> > in that case (and you're in that case if you're behind a proxy
>> because
>> > java.net website uses https protocol) there is still a
>> workaround; use
>> > the following system properties when using maven :
>> >
>> > -Dhttps.proxyHost=[proxy] -Dhttps.proxyPort=[port]"
>> >
>> > This was resolved when the order was changed in the POM.
>> >
>> > RG
>> >
>>
>>
>> --
>> Martin Ritchie
>>
>
>
> --
> Martin Ritchie
Re: Maven build
Posted by Martin Ritchie <ri...@apache.org>.
Qpid-developers,
There are still a few issues I've noted with using the mvn branch for
M1. Most of the issues are quite small but we need to start testing
and working on the rest of the release process without holding up M2
development.
Build:
- Mina jar is downloaded rather than using our existing snapshot.
Both Distributions
- Top level License file doesn't reference or include all other license files.
- Disclaimer content is wrong. (currently for CXF)
Source Distribution
- AMQP Specification is not included so compilation cannot occur, see
mvn output at end of email.
- Should the source include sufficient files to be able to do a
release? or should it just be the project source files for compilation.
Binary Distribution
- Windows batch scripts no longer work as the <module>-launcher.jars
are not generated.
- META-INF directory in generated jars are missing Disclaimer,License and Notes
- No JavaDoc in the doc folder
- Management module is missing
Other issues
- Library naming, how do we do a Release rather than a snapshot?
- Should we include an empty log directory in the binary build?
I know Steve has put a LOT of good work into getting maven together. My
understanding of the M1 release was so we had baseline to support our
current clients.
Is there any other issues that anyone else has noticed?
--
Martin
Here is the error I get trying to do a mvn from the source release:
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO] Qpid
[INFO] Qpid Common Utilities
[INFO] Qpid Broker
[INFO] Qpid Client
[INFO] Qpid Management
[INFO] Qpid Management Core
[INFO] Qpid Management Client
[INFO] Qpid Cluster
[INFO] Qpid System Tests
[INFO] ----------------------------------------------------------------------------
[INFO] Building Qpid
[INFO] task-segment: [install]
[INFO] ----------------------------------------------------------------------------
[INFO] [site:attach-descriptor]
[INFO] [install:install]
[INFO] Installing c:\dev\Apache
Projects\Qpid-Head\Qpid\branches\mvn\distribution\target\qpid-1.0-in
cubator-M1-SNAPSHOT-java-src\qpid-1.0-incubator-M1-SNAPSHOT-src\pom.xml
to c:\.mvn\repository\org\ap
ache\qpid\qpid\1.0-incubator-M1-SNAPSHOT\qpid-1.0-incubator-M1-SNAPSHOT.pom
[INFO] ----------------------------------------------------------------------------
[INFO] Building Qpid Common Utilities
[INFO] task-segment: [install]
[INFO] ----------------------------------------------------------------------------
[INFO] [antrun:run {execution: protocol-version}]
[INFO] Executing tasks
generate:
[mkdir] Created dir: C:\dev\Apache
Projects\Qpid-Head\Qpid\branches\mvn\distribution\target\qpid
-1.0-incubator-M1-SNAPSHOT-java-src\qpid-1.0-incubator-M1-SNAPSHOT-src\common\target\generated\xsl\o
rg\apache\qpid\framing
[copy] Copying 1 file to C:\dev\Apache
Projects\Qpid-Head\Qpid\branches\mvn\distribution\target
\qpid-1.0-incubator-M1-SNAPSHOT-java-src\qpid-1.0-incubator-M1-SNAPSHOT-src\common\target\generated\
xsl\org\apache\qpid\framing
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Error executing ant tasks
Embedded error: The following error occurred while executing this line:
C:\dev\Apache Projects\Qpid-Head\Qpid\branches\mvn\distribution\target\qpid-1.0-incubator-M1-SNAPSHO
T-java-src\qpid-1.0-incubator-M1-SNAPSHOT-src\common\protocol-version.xml:106:
The following error o
ccurred while executing this line:
C:\dev\Apache Projects\Qpid-Head\Qpid\branches\mvn\distribution\target\qpid-1.0-incubator-M1-SNAPSHO
T-java-src\qpid-1.0-incubator-M1-SNAPSHOT-src\common\protocol-version.xml:49:
ERROR: AMQP specificat
ion file ../../../trunk/qpid/specs/amqp-8.0.xml not found.
[INFO] ------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 3 seconds
[INFO] Finished at: Tue Nov 14 08:40:19 GMT 2006
[INFO] Final Memory: 7M/14M
[INFO] ------------------------------------------------------------------------
On 14/11/06, Martin Ritchie <ri...@apache.org> wrote:
> There are still a few problems with the mvn distribution:
>
> Both Distributions
> -Top level License file doesn't reference or include all other license files.
>
> Source Distribution
> - AMQP Specification is not included so compilation cannot occur, see
> mvn output at end of email.
> - Should the source include sufficient files to be able to do a
> release? Should it not just be the project source files for
> compilation.
>
> Binary Distribution
> - Windows batch scripts no longer work as the <module>-launcher.jars
> are not generated.
> - META-INF directory is missing Disclaimer,License and Notes
> - Library naming, how do we do a Release rather than a snapshot?
>
> There is quite a list of things that need to be resolved. I know Steve
> has put a LOT of good work into getting maven together. My
> understanding of the M1 release was so we had baseline to support our
> current clients.
>
> Given that our current schedule is to do a M2 before Christmas what is
> the groups view?
>
> [ ] Branch now for M1
> [ ] Fix outstanding maven issues for M2 which is around 4 weeks from now.
>
> --
> Martin
>
>
> Here is the error I get trying to do a mvn from the source release:
> [INFO] Scanning for projects...
> [INFO] Reactor build order:
> [INFO] Qpid
> [INFO] Qpid Common Utilities
> [INFO] Qpid Broker
> [INFO] Qpid Client
> [INFO] Qpid Management
> [INFO] Qpid Management Core
> [INFO] Qpid Management Client
> [INFO] Qpid Cluster
> [INFO] Qpid System Tests
> [INFO] ----------------------------------------------------------------------------
> [INFO] Building Qpid
> [INFO] task-segment: [install]
> [INFO] ----------------------------------------------------------------------------
> [INFO] [site:attach-descriptor]
> [INFO] [install:install]
> [INFO] Installing c:\dev\Apache
> Projects\Qpid-Head\Qpid\branches\mvn\distribution\target\qpid-1.0-in
> cubator-M1-SNAPSHOT-java-src\qpid-1.0-incubator-M1-SNAPSHOT-src\pom.xml
> to c:\.mvn\repository\org\ap
> ache\qpid\qpid\1.0-incubator-M1-SNAPSHOT\qpid-1.0-incubator-M1-SNAPSHOT.pom
> [INFO] ----------------------------------------------------------------------------
> [INFO] Building Qpid Common Utilities
> [INFO] task-segment: [install]
> [INFO] ----------------------------------------------------------------------------
> [INFO] [antrun:run {execution: protocol-version}]
> [INFO] Executing tasks
>
> generate:
> [mkdir] Created dir: C:\dev\Apache
> Projects\Qpid-Head\Qpid\branches\mvn\distribution\target\qpid
> -1.0-incubator-M1-SNAPSHOT-java-src\qpid-1.0-incubator-M1-SNAPSHOT-src\common\target\generated\xsl\o
> rg\apache\qpid\framing
> [copy] Copying 1 file to C:\dev\Apache
> Projects\Qpid-Head\Qpid\branches\mvn\distribution\target
> \qpid-1.0-incubator-M1-SNAPSHOT-java-src\qpid-1.0-incubator-M1-SNAPSHOT-src\common\target\generated\
> xsl\org\apache\qpid\framing
> [INFO] ------------------------------------------------------------------------
> [ERROR] BUILD ERROR
> [INFO] ------------------------------------------------------------------------
> [INFO] Error executing ant tasks
>
> Embedded error: The following error occurred while executing this line:
> C:\dev\Apache Projects\Qpid-Head\Qpid\branches\mvn\distribution\target\qpid-1.0-incubator-M1-SNAPSHO
> T-java-src\qpid-1.0-incubator-M1-SNAPSHOT-src\common\protocol-version.xml:106:
> The following error o
> ccurred while executing this line:
> C:\dev\Apache Projects\Qpid-Head\Qpid\branches\mvn\distribution\target\qpid-1.0-incubator-M1-SNAPSHO
> T-java-src\qpid-1.0-incubator-M1-SNAPSHOT-src\common\protocol-version.xml:49:
> ERROR: AMQP specificat
> ion file ../../../trunk/qpid/specs/amqp-8.0.xml not found.
> [INFO] ------------------------------------------------------------------------
> [INFO] For more information, run Maven with the -e switch
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 3 seconds
> [INFO] Finished at: Tue Nov 14 08:40:19 GMT 2006
> [INFO] Final Memory: 7M/14M
> [INFO] ------------------------------------------------------------------------
>
> On 14/11/06, Robert Greig <ro...@gmail.com> wrote:
> > On 13/11/06, Daniel Kulp <da...@iona.com> wrote:
> > > > > Hi Martin, that's odd, since mina 1.0.0 exists under the central
> > > > > repository at http://repo1.maven.org/maven2:
> > > > >
> > > > > <http://repo1.maven.org/maven2/org/apache/mina/>
> > > > >
> > > > > Maybe you just hit a network glitch or something like that?
> > > >
> > > > I am seeing exactly the same problem - have tried a few times. Is
> > > > there any special configuration required?
> >
> > The problem was this:
> >
> > "Maven 2.0.4 and lower, doesn't support https and proxy so if you're
> > in that case (and you're in that case if you're behind a proxy because
> > java.net website uses https protocol) there is still a workaround; use
> > the following system properties when using maven :
> >
> > -Dhttps.proxyHost=[proxy] -Dhttps.proxyPort=[port]"
> >
> > This was resolved when the order was changed in the POM.
> >
> > RG
> >
>
>
> --
> Martin Ritchie
>
--
Martin Ritchie
Re: Maven build
Posted by Robert Greig <ro...@gmail.com>.
On 13/11/06, Daniel Kulp <da...@iona.com> wrote:
> > > Hi Martin, that's odd, since mina 1.0.0 exists under the central
> > > repository at http://repo1.maven.org/maven2:
> > >
> > > <http://repo1.maven.org/maven2/org/apache/mina/>
> > >
> > > Maybe you just hit a network glitch or something like that?
> >
> > I am seeing exactly the same problem - have tried a few times. Is
> > there any special configuration required?
The problem was this:
"Maven 2.0.4 and lower, doesn't support https and proxy so if you're
in that case (and you're in that case if you're behind a proxy because
java.net website uses https protocol) there is still a workaround; use
the following system properties when using maven :
-Dhttps.proxyHost=[proxy] -Dhttps.proxyPort=[port]"
This was resolved when the order was changed in the POM.
RG
Re: Maven build
Posted by Daniel Kulp <da...@iona.com>.
On Monday November 13 2006 1:33 pm, Robert Greig wrote:
> On 13/11/06, Steve Vinoski <vi...@iona.com> wrote:
> > Hi Martin, that's odd, since mina 1.0.0 exists under the central
> > repository at http://repo1.maven.org/maven2:
> >
> > <http://repo1.maven.org/maven2/org/apache/mina/>
> >
> > Maybe you just hit a network glitch or something like that?
>
> I am seeing exactly the same problem - have tried a few times. Is
> there any special configuration required?
>
> RG
You aren't using some out of date mirror in your settings.xml, are you?
I'd try disabling any mirrors in your settings.xml and see if that helps.
You might want to "rm -rf ~/.m2/repository/org/apache/mina" and retry.
It could have gotten a corrupt pom or something which is confusing it.
I just tried "rm -rf ~/.m2" to completely wipe out all my local stuff and
re-ran and it seems to go OK and all tests passed. I really don't
like the amount of crap going to stdout during the tests. (I'm a believer
that passing tests should do so SILENTLY. Only failing tests should
output stuff) However, that issue doesn't affect it actually building
and running.
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194 F:781-902-8001
daniel.kulp@iona.com
Re: Maven build
Posted by Robert Greig <ro...@gmail.com>.
On 13/11/06, Steve Vinoski <vi...@iona.com> wrote:
>
> Hi Martin, that's odd, since mina 1.0.0 exists under the central
> repository at http://repo1.maven.org/maven2:
>
> <http://repo1.maven.org/maven2/org/apache/mina/>
>
> Maybe you just hit a network glitch or something like that?
I am seeing exactly the same problem - have tried a few times. Is
there any special configuration required?
RG
Re: Maven build
Posted by Steve Vinoski <vi...@iona.com>.
On Nov 13, 2006, at 12:00 PM, Martin Ritchie wrote:
> Steve,
>
> I'm getting the following error from mvn under cygwin.
>
> command: "mvn"
<snip/>
Hi Martin, that's odd, since mina 1.0.0 exists under the central
repository at http://repo1.maven.org/maven2:
<http://repo1.maven.org/maven2/org/apache/mina/>
Maybe you just hit a network glitch or something like that?
--steve
> .
> .
> .
>
> [INFO]
> ----------------------------------------------------------------------
> ------
> [INFO] Building Qpid Broker
> [INFO] task-segment: [install]
> [INFO]
> ----------------------------------------------------------------------
> ------
> [INFO] [resources:resources]
> [INFO] Using default encoding to copy filtered resources.
> Downloading: https://maven-repository.dev.java.net/nonav/
> repository//org.apache.mina/poms/mina-java5
> -1.0.0.pom
> [INFO]
> ----------------------------------------------------------------------
> --
> [ERROR] BUILD ERROR
> [INFO]
> ----------------------------------------------------------------------
> --
> [INFO] Error building POM (may not be this project's POM).
>
>
> Project ID: org.apache.mina:mina-java5
>
> Reason: Error getting POM for 'org.apache.mina:mina-java5' from the
> repository: Error transferring f
> ile
> org.apache.mina:mina-java5:pom:1.0.0
>
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2),
> java.net (https://maven-repository.dev.java.net/nonav/repository/),
> apache.snapshots (http://people.apache.org/repo/m2-snapshot-
> repository)
>
>
> -----
>
> The common bits seem to compile ok but the broker looks like it is
> failing to download mina. I'm not to up on maven but hte three urls
> don't seem to have the pom file.
>
> I'm using:
> maven 2.0.4
> java 1.5.0_08
>
> Any thoughts?
> --
> Martin Ritchie