to be consolidated into a dependency
management section in the top level pom or perhaps move our top level
dependency from genesis to geronimo. Initially the versions were
distributed so that samples could be built independently but we now
require an initial top level build of samples.
Joe
Joe Bohn wrote
Joe Bohn wrote:
Grrr every time I hope to get a samples image up for vote I
discover (or rediscover) some issues that should be resolved.
Here are the latest issues:
- Most of the samples when run include a Geronimo header with links that
are supposed to take you to javadocs and xref
I'd be fine with either option. It's certainly simple enough to add the
privacy clause. We can do that for now even if we decide to remove
Analytics entirely later on. I personally haven't been checking the
Google Analytics very often but perhaps others have been making more use
of it?
David Jencks wrote:
On Sep 15, 2008, at 11:41 AM, Joe Bohn wrote:
David Jencks wrote:
On Sep 15, 2008, at 10:45 AM, Joe Bohn wrote:
David Jencks wrote:
On Sep 15, 2008, at 6:18 AM, Joe Bohn wrote:
Thanks for making these changes David. I think this mostly
addresses my concern
candidate and vote without the
doc being complete. ... I've been dragging my feet on the doc (there's
always something else to work on :-) ).
Lin
On Wed, Sep 17, 2008 at 2:09 PM, Joe Bohn [EMAIL PROTECTED] wrote:
Joe Bohn wrote:
- Most of the samples when run include a Geronimo header
integrated into the maven release process. So, for now I'm trying
to get mvn site (depending on the configuration from genesis as much as
possible) to generate a usable site so samples can be treated like any
other project when released.
Joe
Joe Bohn wrote:
Lin Sun wrote:
Joe, thanks
Is it just temporary that the wiki on installing Geronimo Eclipse Plugin
2.1.3 is a child of 2.1.2 rather than a peer?
Everything else that I looked at looked fine.
Joe
Ted Kirby wrote:
The vote on GEP 2.1.3 has been started, and this is the associated
discussion thread.
Fan mail goes
+1 - Looks good to me.
In addition to installing and creating and running the sample I also
took a quick look at the source and all seems to be in order.
Thanks for pulling this together Ted!
Joe
Ted Kirby wrote:
G 2.1.3 has been released, and there has been no activity in GEP trunk
for a
Ted,
I didn't know if Donald had already done so or not .. but I just forced
the export for the site just in case.
Joe
Ted Kirby wrote:
OK, I've got
http://cwiki.apache.org/confluence/display/GMOxSITE/Development+Tools
in shape. I want it to be the new
done
Ted Kirby wrote:
Thanks Joe. I had not updated the Devtools link in the subproject
left nav to pick up the new page. I just did so now. Can you force
the export again?
Thanks,
Ted
On Sat, Sep 20, 2008 at 5:02 PM, Joe Bohn [EMAIL PROTECTED] wrote:
Ted,
I didn't know if Donald had
Yep, that's pretty ancient. So it looks like we haven't released
javadoc for Geronimo since the referenced link to 2.0.1.
Does anybody know if the plan was to start using a maven generated site
to produce provide this and we just haven't implemented it yet?
There is a maven site out there
Jason Dillon wrote:
On Sep 22, 2008, at 11:57 PM, Joe Bohn wrote:
Yep, that's pretty ancient. So it looks like we haven't released
javadoc for Geronimo since the referenced link to 2.0.1.
Does anybody know if the plan was to start using a maven generated
site to produce provide this and we
Is there ever a valid need to specify relativePath in the parent section
of our poms?
I noticed that nearly all of the relativePath entries have been removed
from trunk but not branches/2.1. The only existing relativePath entries
in trunk are for concurrent-testsuite and command-testsuite
. Context will not be modified.
META-INF/maven/site.vm [line 17, column 1]
snip/
and
[ERROR] BUILD ERROR
[INFO]
[INFO] 'helpmojo' was specified in an execution, but not found in the plugin
Joe Bohn wrote:
Is there ever
+1000 ... I'd definitely say to commit it. I was just killing firefox
each time it got stuck until I could get around to re-installing the FF2.x.
IIRC, we were using the 1.0-SNAPSHOT when things first started failing
and the change to 1.0-beta-1 was an effort to fix this. It obviously
Probably not the cause of the failures ... but I went ahead and removed
the relativePath references anyway.
Joe
Joe Bohn wrote:
Hmmm ... perhaps it isn't just the relativePath. I just attempted to
build site for trunk and received a similar warning attempting to load a
parent project
It would seem this change:
http://svn.apache.org/viewvc?view=revrevision=698750 precipitated
these failures. I started to notice the failures on my local build (and
even in the trunk samples build).
David B,
Do we need to get a newer snapshot of OpenEJB or perhaps build locally
to bypass
Joe Bohn wrote:
Jason Dillon wrote:
On Sep 22, 2008, at 11:57 PM, Joe Bohn wrote:
Yep, that's pretty ancient. So it looks like we haven't released
javadoc for Geronimo since the referenced link to 2.0.1.
Does anybody know if the plan was to start using a maven generated
site to produce
Jarek Gawor wrote:
So this is really about changing the directory structure in svn and
nothing more, right? I'm not sure about moving buildsupport but I'm ok
with moving the other parts. We could also add a maven profile
(similar to stage-bootstrap) just to build the necessary parts to
build the
I think the problem is in setting the fix version too soon on many of
these JIRAs. For the 2.1.1 and 2.1.2 server releases I tried to avoid
setting the fix version unless it was really a target for the release or
we were ready to check-in a fix. Perhaps we can do the same for devtools.
Joe
I've been trying to use the maven release process for samples.
The dryrun works fine and I've corrected all differences in the poms
beyond the version and scm entries. However, when I attempt the
release:prepare I hit the error below.
customer-ejb has already been processed but the jar only
Nope, there are no install:install goals being run.
Joe
Jason Dillon wrote:
Um... do you see any [install:install] goals being run?
My guess is that the preparation goals are set to clean verify or
something, and should be clean install.
--jason
On Sep 30, 2008, at 1:07 AM, Joe Bohn
Actually, I wonder why it would need to do anything beyond perhaps
validate if the primary task is to update svn with the new tag and versions.
Joe
Joe Bohn wrote:
Nope, there are no install:install goals being run.
Joe
Jason Dillon wrote:
Um... do you see any [install:install] goals
All,
I've prepared a release candidate of Geronimo Samples 2.1.2 for your
review and vote.
This is the first independent release of samples for Geronimo. All
together, there are 86 deliverables included in the staging repository.
There are many documentation updates necessary which can
This a thread to discuss any issues as a result of the Geronimo Samples
2.1.2 vote candidate.
Joe
My +1.
Joe
Joe Bohn wrote:
All,
I've prepared a release candidate of Geronimo Samples 2.1.2 for your
review and vote.
This is the first independent release of samples for Geronimo. All
together, there are 86 deliverables included in the staging repository.
There are many documentation
and worked well. I noticed one issue:
Installable property is not marked correctly mostly, for example we
mark jetty app plugin as installable on tomcat assembly. I think
only one or two is marked correctly initially.
Lin
On Mon, Sep 29, 2008 at 10:44 PM, Joe Bohn [EMAIL PROTECTED] wrote
removed the javadoc and xref
links and generated a standard maven site. You found a link to the old
source that I missed.
/history
Thanks for checking it out.
Joe
Kevan Miller wrote:
On Sep 29, 2008, at 10:44 PM, Joe Bohn wrote:
This a thread to discuss any issues as a result
Friendly reminder to cast your vote. We're halfway through the vote now.
Joe
Joe Bohn wrote:
All,
I've prepared a release candidate of Geronimo Samples 2.1.2 for your
review and vote.
This is the first independent release of samples for Geronimo. All
together, there are 86 deliverables
Jarek Gawor wrote:
A few minor notes:
1) dbtester plugins have prerequisite set which is not consistent
with other plugins. Also, the archetype needs to be updated to remove
the prerequisite stuff.
Yep, I noticed that but since I kinda like the pre-req I let that one
slide ... but you are
The vote passes with 9 +1 (7 from pmc members) and no other votes.
I'll get to work getting the binaries and site pushed out. As usual, it
will take a little while for the images to get synced to the mirrors.
Thanks!
Joe
Joe Bohn wrote:
All,
I've prepared a release candidate of Geronimo
I just updated the source and built from a clean repo on mac OS. I
didn't notice any problems with the assemblies created. The
jetty6-javaee5 assembly had the /bin/scripts marked as executable and
the server seemed to startup fine (except for some warnings about
properties not being
Oh ... and I checked and the
repository/.../geronimo-boilerplate/2.2-SNAPSHOT/geronimo-boilerplate-2.2-SNAPSHOT.car/contents/repository
is present.
Joe
Joe Bohn wrote:
I just updated the source and built from a clean repo on mac OS. I
didn't notice any problems with the assemblies created
Jason Warner wrote:
On Fri, Oct 3, 2008 at 6:55 PM, David Jencks [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
On Oct 3, 2008, at 12:51 PM, Jason Warner wrote:
Hey all. I'm working on an idea for allowing custom valves to
be defined in config.xml. Currently this isn't
comment inline below.
[EMAIL PROTECTED] wrote:
Author: dwoods
Date: Mon Oct 6 07:42:43 2008
New Revision: 702167
URL: http://svn.apache.org/viewvc?rev=702167view=rev
Log:
add in private svn repo so plugin installs can find our rebuilt artifacts
Modified:
Seems reasonable to me. I don't know why we would need to double encode
the %3A and it actually seems like it might cause some problems.
Joe
David Jencks wrote:
There's a new MR for the jacc spec and one of the changes is related to
something we've already tried to solve for dealing with
Just FYI in the server we initially create the release branch via a
copy but then move the branch to a tag when it is released. This
preserves the history in svn and also removes the release branch as
the tag is created. You might want to consider this approach for future
GEP releases.
I agree that groups of plugins are useful and perhaps necessary from a
user perspective to help eliminate the clutter. However, there are
several ways to provide for those groups.
The way that has thus far been pursued has been creating a new module
type (is that what you would call it?) of
Donald Woods wrote:
In-line.
Lin Sun wrote:
Thanks for making the suggestions. It is always good to hear
feedback and challenge our thinking! :)
Yep, I wish we had more than 4 people actively looking/discussing this :-(
Ok ... you asked for it ;-) ... Also see my response on the other
Jason Warner wrote:
Thanks for the explanation, David. I don't disagree with anything
you've explained, but I'm not sure you've addressed my concern about the
disparity in the effort required to deploy a custom valve on tomcat and
on geronimo. Even with the a streamlined process involving a
On Wed, Oct 8, 2008 at 4:10 PM, Joe Bohn [EMAIL PROTECTED] wrote:
I agree that groups of plugins are useful and perhaps necessary from a user
perspective to help eliminate the clutter. However, there are several ways
to provide for those groups.
The way that has thus far been pursued has been
I think it was Kevan that originally proposed we might consider
integrating some of these scripting languages/environments in with
Geronimo ... possibly for Geronimo 2.2.
I've started to look into a few of these technologies with an eye toward
integration in Geronimo. I'm not coming into
Kevan Miller wrote:
On Oct 10, 2008, at 10:52 AM, Jason Dillon wrote:
On Oct 10, 2008, at 4:27 AM, Joe Bohn wrote:
Grails framework - This is a self contained framework that leverages
groovy for scripting. It uses a rails like code by convention
approach to generate and host web
I too agree that a new user should not need to deal with plugins
initially unless they really want to.
I think they can already do this today ... but perhaps not as cleanly as
we would like (and not without the user seeing the word plugin).
The important thing (as David mentioned) is that
There are some issues with the maven generated site. These aren't new
problems and they are doc related ... so I'm not sure if they should
really hinder the spec release.
I just started looking into them since I had some of the same problems
with the recent samples 2.1.2 release (BTW ... not
without
the site?
Jarek
On Mon, Oct 13, 2008 at 11:19 AM, Joe Bohn [EMAIL PROTECTED] wrote:
There are some issues with the maven generated site. These aren't new
problems and they are doc related ... so I'm not sure if they should
really hinder the spec release.
I just started looking into them since
It seems that a number of the commands stopped working on the framework
assembly sometime between the release of 2.1.1 and 2.1.2. The problem
persists in 2.1.3, branches/2.1, and trunk.
These are problems using the shell/batch commands. I know we want to
move over completely to gshell ...
+1 assuming we're still OK with TCK.
Joe
Jarek Gawor wrote:
Hi,
This is a vote for SAAJ 1.3 spec jar version 1.0.1. There was only one
change from version 1.0.0:
https://issues.apache.org/jira/browse/GERONIMO-4289
Staging repo:
Jarek Gawor wrote:
Comments inline:
On Mon, Oct 13, 2008 at 4:39 PM, Joe Bohn [EMAIL PROTECTED] wrote:
It seems that a number of the commands stopped working on the framework
assembly sometime between the release of 2.1.1 and 2.1.2. The problem
persists in 2.1.3, branches/2.1, and trunk
David Jencks wrote:
On Oct 14, 2008, at 6:25 AM, Joe Bohn wrote:
Jarek Gawor wrote:
Comments inline:
On Mon, Oct 13, 2008 at 4:39 PM, Joe Bohn [EMAIL PROTECTED]
wrote:
It seems that a number of the commands stopped working on the framework
assembly sometime between the release of 2.1.1
Joe Bohn wrote:
David Jencks wrote:
On Oct 14, 2008, at 6:25 AM, Joe Bohn wrote:
Jarek Gawor wrote:
Comments inline:
On Mon, Oct 13, 2008 at 4:39 PM, Joe Bohn [EMAIL PROTECTED]
wrote:
It seems that a number of the commands stopped working on the
framework
assembly sometime between
I think it all depends on the amount of tck destabilization and how long
we think it might take to get things resolved.
IMO we should be thinking about releasing 2.2 soon. I'm all for getting
as much ee6 content included as possible ... but if too much breaks in
the tck it could take a
.
Scripting is a very powerful way to extend you application, and I'm
certainly a proponent. But what I'm having trouble realizing is...
for a JavaEE application server, what/how/why would a developer want
to script?
--jason
On Oct 11, 2008, at 1:13 AM, Joe Bohn wrote:
ant elder wrote
I've been making some changes to Genesis 1.5-SNAPSHOT to get maven site
generation working a little bit better and fix a few other things. All
of this is because there were still some maven site generation issues
after releasing samples. I think I have things working better now ...
but I
Jarek,
I think it is OK to make the site public. It isn't perfect from an
appearance perspective but all of the appropriate content is included.
IMO it's better to have something than nothing.
Joe
Jarek Gawor wrote:
Hi,
This vote passes with 10 +1 votes.
I'll push out the binaries
Donald Woods wrote:
In-line.
Joe Bohn wrote:
I've been making some changes to Genesis 1.5-SNAPSHOT to get maven
site generation working a little bit better and fix a few other
things. All of this is because there were still some maven site
generation issues after releasing samples. I
This is a vote for Genesis 1.5.
While trying to get site generation improved for the specs, I discovered
that I needed a few minor changes to genesis. It's been a while since
we released a 1.x version of Genesis, so this also includes other
changes as well. AFAIK this release includes these
Sorry for the quick cancellation. I neglected to update the site.xml
which specifies the version of the geronimo skin and isn't updated
automatically by the maven release process. I'll manually change the
version and put out another vote.
Joe
Joe Bohn wrote:
This is a vote for Genesis
This is a vote for Genesis 1.5.
Take 2:
Same as take 1 except for replacing the hard-coded dependency on
geronimo-skin from 1.5-SNAPSHOT with 1.5 (this release).
Take 1:
While trying to get site generation improved for the specs, I discovered
that I needed a few minor changes to genesis.
Here's my +1
Joe
Joe Bohn wrote:
This is a vote for Genesis 1.5.
Take 2:
Same as take 1 except for replacing the hard-coded dependency on
geronimo-skin from 1.5-SNAPSHOT with 1.5 (this release).
Take 1:
While trying to get site generation improved for the specs, I discovered
that I
I think it was Jarek that first raised the alert that the javadoc
available for the server on our website is still pointing to 2.0.1.
I took a look into generating some updated javadoc for 2.1.3 but
encountered a problem and wonder if anybody has any ideas.
While attempting to build the
Hmmm ... good point. I was just setting it in maven opts (xMx). I'll
try setting it on the plugin config also and see if that helps.
Thanks,
Joe
Jason Dillon wrote:
Are you setting the plugin's maxmemory or just mvn's max?
--jason
On Oct 21, 2008, at 3:30 AM, Joe Bohn wrote:
I think
the heap
size in the plugins configuration.
--jason
On Oct 21, 2008, at 6:33 PM, Joe Bohn wrote:
Hmmm ... good point. I was just setting it in maven opts (xMx). I'll
try setting it on the plugin config also and see if that helps.
Thanks,
Joe
Jason Dillon wrote:
Are you setting the plugin's
I built and checked in the server 2.1.3 javadocs. This seemed to be the
most expedient thing to do but there are some concerns:
#1 This is a huge amount of content to include in svn. I think infra
will not be happy with us.
#2 Given #1, I debated deleting the 2.0.1 javadoc. However, this
soon.
Joe
Joe Bohn wrote:
This is a vote for Genesis 1.5.
Take 2:
Same as take 1 except for replacing the hard-coded dependency on
geronimo-skin from 1.5-SNAPSHOT with 1.5 (this release).
Take 1:
While trying to get site generation improved for the specs, I discovered
that I needed a few
This is a vote for Genesis 1.5.
Take 3:
In addition to take 1 take 2 this includes a more appropriate javadoc
max memory setting.
Take 2:
Same as take 1 except for replacing the hard-coded dependency on
geronimo-skin from 1.5-SNAPSHOT with 1.5 (this release).
Take 1:
While trying to get
that should be
2.1.3 and 2.0.2.
Jarek
On Tue, Oct 21, 2008 at 11:18 AM, Joe Bohn [EMAIL PROTECTED] wrote:
I built and checked in the server 2.1.3 javadocs. This seemed to be the
most expedient thing to do but there are some concerns:
#1 This is a huge amount of content to include in svn. I think infra
Here's my +1
Joe
Joe Bohn wrote:
This is a vote for Genesis 1.5.
Take 3:
In addition to take 1 take 2 this includes a more appropriate javadoc
max memory setting.
Take 2:
Same as take 1 except for replacing the hard-coded dependency on
geronimo-skin from 1.5-SNAPSHOT with 1.5
Congrats and welcome Jason!!!
Joe
Kevan Miller wrote:
All,
Please join us in congratulating Jason Warner as the newest member of
the Geronimo PMC. It's been great to have Jason working with us as a
committer on Geronimo. Even better to have him join us in providing
oversight of the
to list the javadoc
versions, and link to that from the sidenav instead of going directly to
2.1.3.
--jason
On Oct 21, 2008, at 10:18 PM, Joe Bohn wrote:
I built and checked in the server 2.1.3 javadocs. This seemed to be
the most expedient thing to do but there are some concerns:
#1
On Oct 22, 2008, at 6:51 PM, Joe Bohn wrote:
Yes, I was thinking the same thing. I just hadn't gotten to it yet
and I was also a little hesitant because that implies that we will
have the javadoc for all releases. At the moment we only have 2.0.1
and 2.1.3.
Joe
Jason Dillon wrote:
I
I apologize for not raising this question on the earlier thread.
I'm wondering if it is a good idea to release a 2.0.3 at this point in
time. We've had several releases of 2.1.x (four) and we'll hopefully
release 2.2 in the not too distant future. I'm a little concerned that
releasing a
Does anybody know why these dependencies are needed?
- plugins/cxf/cxf/pom.xml contains a dependency on the spring plugin
(org.apache.geronimo.configs/spring//car).
- plugins/axis2/axis2/pom.xml conains a dependency on the jaxen jar.
These are causing some problems when attempting to deploy
The vote passes with 6 +1 (all pmc members) and no other votes.
I'll get to work getting the binaries and site pushed out. As usual, it
will take a little while for the images to get synced to the mirrors.
Thanks!
Joe
Joe Bohn wrote:
This is a vote for Genesis 1.5.
Take 3:
In addition
This is a vote for specs-parent 1.6.
The primary purpose for this release is to utilize the newly released
genesis 1.5 which included some enhancements to facilitate maven site
generation. There are also some minor changes in specs-parent to
facilitate maven site generation. Once released
to announce
to our users that this will be the last 2.0.x release (which we never
really did for 1.1.x) and that they should start moving to 2.1.x or 2.2
for any new projects.
-Donald
Joe Bohn wrote:
I apologize for not raising this question on the earlier thread.
I'm wondering if it is a good
Here's my +1
Joe
Joe Bohn wrote:
This is a vote for specs-parent 1.6.
The primary purpose for this release is to utilize the newly released
genesis 1.5 which included some enhancements to facilitate maven site
generation. There are also some minor changes in specs-parent to
facilitate
Thread to discuss any issues/concerns regarding the release of
specs-parent 1.6.
Joe
and specs-parent 1.7 out prior to any individual spec and
leverage that instead I won't be offended.
Joe
Joe Bohn wrote:
Thread to discuss any issues/concerns regarding the release of
specs-parent 1.6.
Joe
This sounds really cool David! I'm hoping to give it a test drive soon.
Joe
David Jencks wrote:
For a long time we've been talking about having an easy way to create
lots of server instances sharing the same geronimo installation
(GERONIMO-3123). After staring at the farm demo long
David,
I think you must have forgotten something in the check-in. When I
attempt to create a new instance I get the following error from gshell:
/ deploy/new-instance -n myserver1
ERROR NotFoundException: geronimo-commands:new-server-instance
Joe
Joe Bohn wrote:
This sounds really cool
127.0.0.1 RMI Naming
10009 127.0.0.1 JMX Remoting Connector
Geronimo Application Server started
Joe
David Jencks wrote:
umm..., added, now you can find the next thing I left out :-/
david jencks
On Oct 29, 2008, at 8:44 AM, Joe Bohn wrote:
David,
I think you must have forgotten
24 hour notice on the specs-parent 1.6 vote.
Please cast your vote! Vote for change ;-)
Joe
Joe Bohn wrote:
Thread to discuss any issues/concerns regarding the release of
specs-parent 1.6.
Joe
an objection (or if you just want to add
your +1).
Joe
Joe Bohn wrote:
24 hour notice on the specs-parent 1.6 vote.
Please cast your vote! Vote for change ;-)
Joe
Joe Bohn wrote:
Thread to discuss any issues/concerns regarding the release of
specs-parent 1.6.
Joe
The vote passes with 4 +1 (all pmc members) and no other votes.
I'll get to work getting the binaries and site pushed out. As usual, it
will take a little while for the images to get synced to the mirrors.
Thanks!
Joe
Joe Bohn wrote:
This is a vote for specs-parent 1.6.
The primary
Looks like discussion on this thread has died down a bit but the clock
is still ticking ... New Years will be here all too soon and IIUC we're
trying to beat that clock!!
Some things in addition to what you've listed (I'll update the wiki with
these too):
- There are a number of snapshots
I'm certainly in favor of only performing certification on SE 6 runtime
for 2.2.
I wonder if it would be possible for us to include the JAXB and JAXWS
support in a plugin for users that might need to continue on SE 5. If
this isn't too difficult (or too much of a maintenance nightmare) then
Who have you been asking (aside from the [EMAIL PROTECTED])? This is
the first post that I see from you on the Geronimo dev list requesting
this access.
To modify Geronimo documentation you need to request
geronimo-contributor authorization (via this list) after you have
submitted your
It has been mentioned several times that we should be looking to release
Geronimo 2.2 before the end of the year (preferrably mid-December).
Before we can consider a release there are a large number of snapshots
that need to be removed/replaced in our project. Can anybody shed any
light on
Hmm ... it doesn't look like the snapshots were published yet, so I'll
start to push them out later tonight or tomorrow morning.
I'm in the middle of publishing the 2.1.4-SNAPSHOTS now.
Joe
Tim McConnell wrote:
Thanks Donald, that would certainly help
Donald Woods wrote:
Do we need to
Gianny Damour wrote:
On 12/11/2008, at 10:04 AM, Joe Bohn wrote:
It has been mentioned several times that we should be looking to
release Geronimo 2.2 before the end of the year (preferrably
mid-December).
Before we can consider a release there are a large number of snapshots
that need
I think I was one of the people asking for this to be reverted.
Just to clarify my position: I'm very much in favor of keeping the
functionality. I think it will help with some of the more obscure
classloader issues we've been hitting.
My suggestion to revert the change was more pragmatic
Thanks David. I'm not familiar with nexus but I did find this other
handy site that has been useful:
http://mvnrepository.com/
Is nexus similar?
Joe
David Jencks wrote:
On Nov 11, 2008, at 3:04 PM, Joe Bohn wrote:
It has been mentioned several times that we should be looking to
release
-concurrent_1.0_spec 1.0-SNAPSHOT, we can get that
released now. I have no pending updates for it.
Jarek
On Tue, Nov 11, 2008 at 6:04 PM, Joe Bohn [EMAIL PROTECTED] wrote:
It has been mentioned several times that we should be looking to release
Geronimo 2.2 before the end of the year (preferrably mid-December
Gianny Damour wrote:
On 13/11/2008, at 5:13 AM, Joe Bohn wrote:
Gianny Damour wrote:
On 12/11/2008, at 10:04 AM, Joe Bohn wrote:
It has been mentioned several times that we should be looking to
release Geronimo 2.2 before the end of the year (preferrably
mid-December).
Before we can
I started some preliminary work on a grails plugin that could be used to
collect all of the grails dependencies so that they can be shared.
Along with this we would need to provide a mechanism to generate a war
file in grails which does not contain any of the common elements. I'd
like to
for this release).
How big are the dependencies anyways?
About 18MB.
--jason
On Nov 15, 2008, at 5:43 AM, Joe Bohn wrote:
I started some preliminary work on a grails plugin that could be used
to collect all of the grails dependencies so that they can be shared.
Along with this we
Updated information below on our snapshots (and some more
questions/requests).
Joe Bohn wrote:
It has been mentioned several times that we should be looking to release
Geronimo 2.2 before the end of the year (preferrably mid-December).
Before we can consider a release there are a large
I'm obviously in favor of this. It's much more feasible and yet still
very aggressive.
Joe
Donald Woods wrote:
Chatted with Joe and we're thinking that the current 2.2 release dates
on the wiki should be moved out a few weeks to account for snapshots we
still need released -
Donald Woods wrote:
Current thinking is that we'll create branches/2.2 from trunk around
Dec. 12, so we can start closing down the 2.2 release.
What is everyone's thoughts on what version we'll use for trunk when
that happens?
1) trunk becomes 3.0-SNAPSHOT and focused on JEE6
2) trunk
901 - 1000 of 2330 matches
Mail list logo
