Why are we giving the assembly id's the version suffix here? I don't
think we want to do this. I think the ids, which are simply to
select which assembly to use should be tomcat or jetty. IMO, this is
just that much more to type... for no real gain.
These are assembly ids, not artifact
Why are these not in the top-level javamail pom? This was building
fine for me as it was... or did someone recently change it to break
things?
Anyways, version details should probably be in the top-level pom, not
in child poms, especially for a small project like this.
--jason
On Dec
When we updated to JavaMail 1.4 and Activation 1.1 we got this warning
message when building trunk:
[WARNING] POM for
'org.apache.geronimo.javamail:geronimo-javamail_1.4_provider:pom:1.0-SNAPSHOT:compile'
is invalid. It will be ignored for artifact resolution.
Reason: Failed to validate POM
I would like to do the same change for trunk. Anybody got
issues/concerns/objections to this?
Best wishes,
chris
Rick McGuire wrote:
There have been 3 javamail questions on the user list in recent weeks
about how to resolve a NoSuchProviderException trying to use SMTP.
These problems all
Hi,
I am quickly scanning this commit and I would like to know if it was
not a little bit less intrusive to keep the existing addOperation and
search for the return type of the added operations against the target
gbeanType. This way, developers do not need to specify the return
type of
Christopher M. Cardona wrote:
I would like to do the same change for trunk. Anybody got
issues/concerns/objections to this?
There's an open JIRA for doing this that's marked as a wish item.
http://issues.apache.org/jira/browse/GERONIMO-2498
I'd say go for it.
Rick
Best wishes,
chris
I removed the legacy java.net repo from the root pom Friday PM. Are
there others?
Joe
Jason Dillon wrote:
Strange dependency muck like this often happens when a legacy repo is
in the mix.
--jason
On Dec 10, 2006, at 8:55 PM, anita kulshreshtha wrote:
When I build cxf-builder from
[
https://issues.apache.org/activemq/browse/AMQ-591?page=comments#action_37642 ]
james strachan commented on AMQ-591:
Here's the latest links...
http://incubator.apache.org/activemq/security.html
add a per message authorization hook so
Hi,
I am trying to debug a couple of test-ejbcontainer itests and the
test-ejbcontainer itests seem to be broken (I was able to run them on
Friday last week) as the org.apache.geronimo.configs/j2ee-corba-yoko/
2.0-SNAPSHOT/car configuration cannot be started due to the following
reason:
HttpBridgeServlet is not initialize when using jetty 6.1pre3
Key: SM-770
URL: https://issues.apache.org/activemq/browse/SM-770
Project: ServiceMix
Issue Type: Improvement
When creating geronimo-web.xml from scratch using Plug-in Form Editor, the
Dependencies view doesn't show the just added dependency
-
Key:
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-122?page=all ]
Shiva Kumar H R updated GERONIMODEVTOOLS-122:
-
Attachment: GERONIMODEVTOOLS-122.patch
When creating geronimo-web.xml from scratch using Plug-in Form Editor, the
[
http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-117?page=comments#action_12457322
]
Shiva Kumar H R commented on GERONIMODEVTOOLS-117:
--
I wasn't talking about the ArrayStoreException which definitely is fixed in
trunk,
[
http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-118?page=comments#action_12457325
]
Shiva Kumar H R commented on GERONIMODEVTOOLS-118:
--
Apply the patch available in GERONIMODEVTOOLS-122
[ https://issues.apache.org/activemq/browse/SM-770?page=all ]
Jonas Lim resolved SM-770.
--
Resolution: Fixed
resolved in trunk : r485654
added call to handler.initialize() before calling context.start() .
This should still work using the current jetty version
Gianny,
Thanks for looking into this. I did consider the easy way out. But
the retrun type is part of the method signature. What happens if we
have
public class Myclass {
public Object getObjectName()
public String getObjectName()
..
}
If JMXUtil was patched which
The GOpeartionInfo has a field:
private final String methodName;
Which should really have been targetClass or returnType. Currently
it is initialized to the name of the method! If we must maintain
backward compatibility, I am open to suggestions..
Thanks
Anita
--- Gianny Damour [EMAIL
It is not allowed to have public Object getObjectName() and public String
getObjectName() simultaneously.
--vamsi
On 12/11/06, anita kulshreshtha [EMAIL PROTECTED] wrote:
Gianny,
Thanks for looking into this. I did consider the easy way out. But
the retrun type is part of the method
No i have my own Requestor class in whih i am creating request queue using
method :
Destination requestQueue = session.createQueue(requestQueueName);
I have multiple clients accessing this requestor class...i want to share the
request queue among multiple clients
so i want to have some method
Not sure if the file got uploaded, here is the xml file:
?xml version=1.0?
beans xmlns:jsr181=http://servicemix.apache.org/jsr181/1.0;
xmlns:demo=urn:servicemix:soap-binding
xmlns:sm=http://servicemix.apache.org/config/1.0;
classpath
location./location
/classpath
Just create a queue in each client as there is really only one queue
for a given name in a broker. See...
http://incubator.apache.org/activemq/how-do-i-create-new-destinations.html
On 12/11/06, garima015 [EMAIL PROTECTED] wrote:
No i have my own Requestor class in whih i am creating request
I agree with you. But then I thoght I'd use the -DassemblyId param in
one other place in the testsuite; the console-testsuite. The
webconsole-tomcat6 or webconsole-jetty6 car needs to be started and
stopped in the console-testsuite. Instead of using yet another config
param, I thought we could
Jason V,
Copying you for your feedback and awareness.
On Dec 8, 2006, at 6:06 PM, Jason Dillon wrote:
Maven does not behave well with a mix of default and legacy repos.
I have gone through and moved all legacy repos only to the modules
where they are used, and in some cases imported a
Ok looks like the MyFaces team is not going to product any 1.2 snapshots quite yet, but
they have provided permission for me to include the 1.2 myfaces snapshots I've build into
M1. I just need some instructions on how and where to this. Please advise. Thanks
Tim
Tim McConnell wrote:
Looks
When we add inteface using addInterface(..), we can end up with two
methods like this. This is not a very good example because the
objectName will end up as an attribute in GBeanInfoBuilder, not an
operation.
thanks
Anita
--- Vamsavardhana Reddy [EMAIL PROTECTED] wrote:
It is not allowed to
Didn't Paul just publish a snapshot? Wherever that was, can we just
publish it there?
On Dec 11, 2006, at 10:14 AM, Tim McConnell wrote:
Ok looks like the MyFaces team is not going to product any 1.2
snapshots quite yet, but they have provided permission for me to
include the 1.2 myfaces
FYI -- the following artifactIds are now renamed to use tomcat6.
org.apache.geronimo.configs/tomcat6
org.apache.geronimo.configs/tomcat6-deployer
org.apache.geronimo.modules/geronimo-tomcat6
org.apache.geronimo.modules/geronimo-tomcat6-builder
welcome app not included in the jetty assembly.
---
Key: GERONIMO-2642
URL: http://issues.apache.org/jira/browse/GERONIMO-2642
Project: Geronimo
Issue Type: Bug
Security Level: public
Hi All,
I updated most of the Geronimo v1.2 doc. I couldn't get rid of the *SNAPSHOT* for some
screen captures so I guess it will be better to wait till the snapshot is
removed from the build to finish updating those articles.
I listed at the top of the page those articles that have not been
[ http://issues.apache.org/jira/browse/GERONIMO-2642?page=all ]
Prasad Kashyap reassigned GERONIMO-2642:
Assignee: Joe Bohn
Creating this just a placeholder and assigning this to you since you said
you'll look at it. You may reassign this to
It would be nice if before renaming/moving directories, a note
announcing the change could be sent to the list. This will give people
a chance to rename their local copies and avoid getting them wiped out
by an svn update.
Thanks
Anita
--- Paul McMahan [EMAIL PROTECTED] wrote:
FYI -- the
Should the configs that are specific to these artifacts also be renamed?
For example we have org.apache.geronimo.configs/webconsole-jetty6 but
org.apache.geronimo.configs/webconsole-tomcat and the same for dojo.
I'm asking because I was just about to update the welcome-jetty to
[
https://issues.apache.org/activemq/browse/AMQ-591?page=comments#action_37644 ]
John Kurtz commented on AMQ-591:
How does this relate to bug AMQ-775?
http://issues.apache.org/activemq/browse/AMQ-775
add a per message authorization hook so
Also, keep in mind that there is no way to bypass the
local repository afaik. So if a bad artifact goes into the
user local repo, it may disturb Geronimo's build, even
if Geronimo build only use a single svn based remote
repo. In such a case, the only way to ensure that the
build will work is
[
https://issues.apache.org/activemq/browse/AMQ-775?page=comments#action_37645 ]
John Kurtz commented on AMQ-775:
cross reference to: AMQ-591...
https://issues.apache.org/activemq/browse/AMQ-591
MessageAuthorizationPolicy doesn't work
Stack trace (due to amq) while shutting down Geronimo
-
Key: GERONIMO-2643
URL: http://issues.apache.org/jira/browse/GERONIMO-2643
Project: Geronimo
Issue Type: Bug
Security Level:
Geronimo - Monday, December 11, 2006
4 Patches in RTC
[GERONIMO-2485] PersistenceUnitGBean needs a NamespaceDrivenDeployer
- Assignee: David Jencks
- Reporter: David Jencks
- Created: Wed Oct 11 21:23:29 GMT 2006
- Updated: Thu Dec 07 20:28:27 GMT 2006
-
[ http://issues.apache.org/jira/browse/GERONIMO-2638?page=all ]
Sachin Patel updated GERONIMO-2638:
---
Fix Version/s: 2.0-M2
(was: 2.0-M1)
Improve ModuleBuilder and ConfigurationBuilder interfaces to replace use of
JarFile
Prasad,
I am hoping that the fix Dain promised for the branch might help
with this too..
I am waiting for it :)
On Dec 7, 2006, at 10:32 AM, Dain Sundstrom wrote:
We have an exception being thrown in shutdown from
GBeanBinding.removeBinding():159 and I'll fix that today.
My apologies, I had thought that the discussion on dev plus mail from
scm would be sufficient notification but I could have also sent a
heads-up notice. I also didn't realize svn could lose your local
changes from an update -- usually it automatically merges them or
marks a conflict and saves
On 12/11/06, Joe Bohn [EMAIL PROTECTED] wrote:
Should the configs that are specific to these artifacts also be renamed?
For example we have org.apache.geronimo.configs/webconsole-jetty6 but
org.apache.geronimo.configs/webconsole-tomcat and the same for dojo.
I'm asking because I was just
No problem.. It was late at night. My commit failed because something
was not up-to-date. So I did svn update without checking the commit
messages. The tomcat and tomcat-builder modules were gone! We must
remember that everyone does not have access to commit messages.
Thanks
Anita
--- Paul
Thanks for ur reply.I got my mistake.
James.Strachan wrote:
Just create a queue in each client as there is really only one queue
for a given name in a broker. See...
http://incubator.apache.org/activemq/how-do-i-create-new-destinations.html
On 12/11/06, garima015 [EMAIL PROTECTED]
IIUC the myfaces jar isn't part of an official (i.e. voted upon)
release or even considered a snapshot and we don't know
if/when/how/where it will be published. Can we localize it in the
module that needs it? See the dojo.zip in
applications/geronimo-dojo/repository for an example.
Best
David,
I wanted to get something committed that works for now. With trunk rev.
485719 I included jstl as a dependency in
modules/geronimo-web-2.5-builder as well as in configs/jetty6 and
configs/tomcat6 so that it would always be in the classpath for an
application. I can change this if
In a short while (probably in about 3 hours or so), I plan to delete the
and rename several Jetty items in Geronimo. This is because we are no
longer supporting the j2ee assembly in trunk which IIUC is now devoted
to JavaEE5. There are also a few loose ends for the Jetty JavaEE5
assembly
On Dec 11, 2006, at 7:18 AM, anita kulshreshtha wrote:
When we add inteface using addInterface(..), we can end up with two
methods like this.
You can't have a class that implements both interfaces if they have
methods whose signature differs only in the return type. If there
are
Fine with me, thanks for cleaning this up!
thanks
david jencks
On Dec 11, 2006, at 9:42 AM, Joe Bohn wrote:
In a short while (probably in about 3 hours or so), I plan to
delete the and rename several Jetty items in Geronimo. This is
because we are no longer supporting the j2ee assembly
Do we need to include the jetty version number in the configs that
support the applications/* artifacts? My take away from the tomcat v6
conversation was that the version number was for the artifacts that
incorporate the third party component plus their configs and
assemblies. But I realize that
On Dec 11, 2006, at 5:38 AM, anita kulshreshtha wrote:
Gianny,
Thanks for looking into this. I did consider the easy way out. But
the retrun type is part of the method signature. What happens if we
have
public class Myclass {
public Object getObjectName()
public String getObjectName()
On Dec 11, 2006, at 9:18 AM, Joe Bohn wrote:
David,
I wanted to get something committed that works for now. With trunk
rev. 485719 I included jstl as a dependency in modules/geronimo-
web-2.5-builder as well as in configs/jetty6 and configs/tomcat6 so
that it would always be in the
On Dec 11, 2006, at 8:33 AM, anita kulshreshtha wrote:
Prasad,
I am hoping that the fix Dain promised for the branch might help
with this too..
I am waiting for it :)
On Dec 7, 2006, at 10:32 AM, Dain Sundstrom wrote:
We have an exception being thrown in shutdown from
The versioning policy for our geronimo specs has been floating around
for a while now. I'd like to see this issue resolved.
There have been two approaches discussed
1) Single version -- all specs are released under the same version
number.
2) Separate version -- each spec is versioned
Good suggestion Paul, I like that idea.
Tim
Paul McMahan wrote:
IIUC the myfaces jar isn't part of an official (i.e. voted upon)
release or even considered a snapshot and we don't know
if/when/how/where it will be published. Can we localize it in the
module that needs it? See the
I'm seeing a different problem. The openejb-itests-core cannot be
distributed since it has a dependency on j2ee-corba-yoko/1.2-SNAPSHOT.
Here's how the chain is broken.
- Geronimo 2.0-SNAPSHOT pulls in OpenEJB 2.2.
- OpenEJB 2.2 has a dependency on Geronimo 1.2-SNAPSHOT.
Cheers
Prasad
On
I've been seeing it on all recent 2.0-SNAPSHOT assemblies.
Just hit cntlr+c in a running geronimo window or use the shutdown. The
geronimo.log would have the stacktrace or the window running the
server would, depending on how you started it.
Cheers
Prasad
On 12/11/06, Dain Sundstrom [EMAIL
Geronimo 2.0-SNAPSHOT pulls in OpenEJB-2.2
OpenEJB-2.2 has a dependency on Geronimo-1.2-SNAPSHOT
Cheers
Prasad
I'm in favor of a single version for all specs. Versioning the specs
individually has some advantages but makes the release manager's job
more difficult since the tooling doesn't readily support that
approach. And as a developer (at least for me) a single version is
more intuitive, evidenced by
On 12/10/06, David Jencks [EMAIL PROTECTED] wrote:
On Dec 8, 2006, at 1:29 PM, Prasad Kashyap wrote:
David,
Check out this patch http://people.apache.org/~prasad/manifestcp.patch
Apply it from the geronimo/testsuite/depoyment-testsuite directory.
It will create 2 directories under it.
Starting and stopping the server for each app ? Wouldn't that be a tad too much.
Currently the start/stop is designed to happen for a suite (eg. web).
So a bunch of related tests (servlet tests, jsp tests, jsf tests etc)
can be performed in a suite with required apps getting deployed and
On Dec 11, 2006, at 10:44 AM, Prasad Kashyap wrote:
I'm seeing a different problem. The openejb-itests-core cannot be
distributed since it has a dependency on j2ee-corba-yoko/1.2-SNAPSHOT.
What is the error you get?
Here's how the chain is broken.
- Geronimo 2.0-SNAPSHOT pulls in OpenEJB
On Dec 11, 2006, at 10:51 AM, Prasad Kashyap wrote:
Geronimo 2.0-SNAPSHOT pulls in OpenEJB-2.2
OpenEJB-2.2 has a dependency on Geronimo-1.2-SNAPSHOT
All org.apache.geronimo.* deps in OpenEJB were marked as non-
transitive. It's been very heavily tested that you can build G 2.0-
SNAPSHOT
Prasad Kashyap wrote:
Geronimo 2.0-SNAPSHOT pulls in OpenEJB-2.2
OpenEJB-2.2 has a dependency on Geronimo-1.2-SNAPSHOT
When the openejb-2.2 branch was created, the Geronimo branch was updated
to have a dependency on OpenEJB-2.3. How did this get back to a 2.2
dependency?
Rick
Cheers
Yes. I have been able to build Geronimo-2.0-SNAPSHOT on a clean repo
without pulling in anything from 1.2 (except
tranql-connector-derby-common).
However, when I build Openejb-2.2, it pulls in all Geronimo-1.2 artifacts.
Next, the openjeb-itests-core.jar now fails to install on
On 12/11/06, David Blevins [EMAIL PROTECTED] wrote:
On Dec 11, 2006, at 10:44 AM, Prasad Kashyap wrote:
I'm seeing a different problem. The openejb-itests-core cannot be
distributed since it has a dependency on j2ee-corba-yoko/1.2-SNAPSHOT.
What is the error you get?
[INFO] [INFO]
Fix leaking ClassLoaders
Key: GERONIMO-2644
URL: http://issues.apache.org/jira/browse/GERONIMO-2644
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Components: kernel
On Dec 11, 2006, at 11:36 AM, Prasad Kashyap wrote:
Yes. I have been able to build Geronimo-2.0-SNAPSHOT on a clean repo
without pulling in anything from 1.2
Great.
(except tranql-connector-derby-common).
As far as I can see, both G 1.2 and 2.0 are using the exact same
versions of all
On Dec 11, 2006, at 10:52 AM, Paul McMahan wrote:
I'm in favor of a single version for all specs. Versioning the specs
individually has some advantages but makes the release manager's job
more difficult since the tooling doesn't readily support that
approach.
Um.. that's not true. Maven has
[ http://issues.apache.org/jira/browse/GERONIMO-2644?page=all ]
Kevan Miller reassigned GERONIMO-2644:
--
Assignee: Kevan Miller
Fix leaking ClassLoaders
Key: GERONIMO-2644
URL:
[ https://issues.apache.org/activemq/browse/SM-762?page=all ]
Jeff Puro resolved SM-762.
--
Resolution: Fixed
Please see notes on attached patches.
Address in WSDL is incorrectly adding the protocol information in the
begining of the URL
[ http://issues.apache.org/jira/browse/GERONIMO-2630?page=all ]
Jarek Gawor updated GERONIMO-2630:
--
Attachment: Clean.java
Attached is a simple Java program that removes any xsd:annotation elements and
XML comments from a specified xsd file. It can be
[ https://issues.apache.org/activemq/browse/SM-762?page=all ]
Jeff Puro reopened SM-762:
--
Address in WSDL is incorrectly adding the protocol information in the
begining of the URL
On Dec 11, 2006, at 1:26 AM, Christopher M. Cardona wrote:
When we updated to JavaMail 1.4 and Activation 1.1 we got this
warning message when building trunk:
[WARNING] POM for 'org.apache.geronimo.javamail:geronimo-
javamail_1.4_provider:pom:1.0-SNAPSHOT:compile' is invalid. It will
be
Not sure... might be getting picked up as a dependency too.
You removed it? Where are you getting jstl 2.0 from now?
--jason
On Dec 11, 2006, at 1:49 AM, Joe Bohn wrote:
I removed the legacy java.net repo from the root pom Friday PM.
Are there others?
Joe
Jason Dillon wrote:
Strange
ServiceMix-Http component has its ConnectionManager shutdown when installed
under the servicemix-web module (managed mode)
--
Key: SM-771
URL:
[ https://issues.apache.org/activemq/browse/SM-771?page=all ]
Jeff Puro updated SM-771:
-
Summary: An IllegalStateException is generated when using an http provider
endpoint when it is deployed using the Servicemix Web war (managed mode).
(was: ServiceMix-Http
[ https://issues.apache.org/activemq/browse/SM-762?page=all ]
Guillaume Nodet resolved SM-762.
Resolution: Fixed
Author: gnodet
Date: Mon Dec 11 12:37:35 2006
New Revision: 485860
URL: http://svn.apache.org/viewvc?view=revrev=485860
Log:
SM-762:
On 12/11/06, Dain Sundstrom [EMAIL PROTECTED] wrote:
On Dec 11, 2006, at 10:52 AM, Paul McMahan wrote:
I'm in favor of a single version for all specs. Versioning the specs
individually has some advantages but makes the release manager's job
more difficult since the tooling doesn't readily
I wish I could say I removed it without any additional qualification.
:-P However, what I actually said was that I removed it *from the root
pom*. I still have references to the java.net as a legacy repo in
modules/geronimo-web-2.5-builder, configs/tomcat6 and configs/jetty6 to
pick up jstl
I attached to https://issues.apache.org/jira/browse/GERONIMO-2630 a
simple Java program that can remove any XML comments or xsd:annotation
elements from a given XSD file. It might be useful to check the
hand-typed files with the the cleaned up files (generated by this tool
using the Sun's
[ https://issues.apache.org/activemq/browse/SM-771?page=all ]
Jeff Puro updated SM-771:
-
Attachment: servicemix-http-connection-manager-3.0.1.patch
The attached file is a patch for ServiceMix 3.0.1. This solves the issue by
setting the connectionManager and
On 12/10/06, David Jencks [EMAIL PROTECTED] wrote:
On Dec 8, 2006, at 1:29 PM, Prasad Kashyap wrote:
David,
Check out this patch http://people.apache.org/~prasad/manifestcp.patch
Apply it from the geronimo/testsuite/depoyment-testsuite directory.
It will create 2 directories under it.
On Dec 11, 2006, at 12:40 PM, Paul McMahan wrote:
On 12/11/06, Dain Sundstrom [EMAIL PROTECTED] wrote:
On Dec 11, 2006, at 10:52 AM, Paul McMahan wrote:
I'm in favor of a single version for all specs. Versioning the
specs
individually has some advantages but makes the release manager's
[
https://issues.apache.org/activemq/browse/AMQCPP-23?page=comments#action_37647
]
Timothy Bish commented on AMQCPP-23:
I've checked a fix into trunk. Seems to work for me, try it out if you can and
let me know if it resolves the issue.
On Dec 11, 2006, at 11:38 AM, Prasad Kashyap wrote:
On 12/11/06, David Blevins [EMAIL PROTECTED] wrote:
On Dec 11, 2006, at 10:44 AM, Prasad Kashyap wrote:
I'm seeing a different problem. The openejb-itests-core cannot be
distributed since it has a dependency on j2ee-corba-yoko/1.2-
On Dec 11, 2006, at 12:40 PM, Paul McMahan wrote:
On 12/11/06, Dain Sundstrom [EMAIL PROTECTED] wrote:
On Dec 11, 2006, at 10:52 AM, Paul McMahan wrote:
I'm in favor of a single version for all specs. Versioning the
specs
individually has some advantages but makes the release manager's
All,
Being the overly optimistic one that I am I'd like to branch trunk
tomorrow in the afternoon. The goal of the branch is to stabilize a
milestone release with the content previously discussed.
So far it looks like we have:
JSF,
Java Mail
Tomcat 6
Jetty 6
JSTL
Java 1.5 ready
and JPA
On Dec 11, 2006, at 3:44 PM, Jarek Gawor wrote:
I attached to https://issues.apache.org/jira/browse/GERONIMO-2630 a
simple Java program that can remove any XML comments or xsd:annotation
elements from a given XSD file. It might be useful to check the
hand-typed files with the the cleaned up
IMHO I like option 3 which is both option 1 and 2. First, I think
all SPECs should be versioned independently as not everyone is
interested in all the specs. If, for instance, the Tomcat dudes
decide to pick up anything we have they would only be interested in a
subset and shouldn't be
I can take web-app_2_3
On Dec 11, 2006, at 4:08 PM, Kevan Miller wrote:
On Dec 11, 2006, at 3:44 PM, Jarek Gawor wrote:
I attached to https://issues.apache.org/jira/browse/GERONIMO-2630 a
simple Java program that can remove any XML comments or
xsd:annotation
elements from a given XSD
stax-api was regressed from 1.0.1 in G1.1.1 to 1.0 in G1.2
--
Key: GERONIMO-2645
URL: http://issues.apache.org/jira/browse/GERONIMO-2645
Project: Geronimo
Issue Type: Bug
On Dec 11, 2006, at 12:43 PM, Joe Bohn wrote:
I wish I could say I removed it without any additional
qualification. :-P However, what I actually said was that I
removed it *from the root pom*. I still have references to the
java.net as a legacy repo in modules/geronimo-web-2.5-builder,
On Dec 11, 2006, at 1:13 PM, Matt Hogstrom wrote:
IMHO I like option 3 which is both option 1 and 2. First, I think
all SPECs should be versioned independently as not everyone is
interested in all the specs. If, for instance, the Tomcat dudes
decide to pick up anything we have they would
WAR without a geronimo-web.xml deploys to the wrong context
---
Key: GERONIMO-2646
URL: http://issues.apache.org/jira/browse/GERONIMO-2646
Project: Geronimo
Issue Type: Bug
Why? I don't see why we would want to make a branch just for 2.0-m1.
SVN is not the best tool for working with many branches, so I would
recommend keeping the active branches to an absolute minimum.
What happened to stabilizing 1.2 and getting that out?
I think that if you want to make
The openejb-itests-core is created in the openejb itself.
http://svn.apache.org/viewvc/incubator/openejb/branches/v2_2/openejb2/itests/
The top level pom in openejb has the geronimoVersion property set to
1.2-SNAPSHOT.
So the itests-core's pom and plans all use this property during
resource
Another Q.
If a branch is made, would the code there have to maintained ? Would
bug fixes in 1.2 be rolled into the trunk as well as the M1 branch ? I
hope not.
I hope it is just for tagging purpose and the code there would not
have to be maintained post M1 release.
Cheers
Prasad
On 12/11/06,
On Dec 11, 2006, at 10:13 AM, Kevan Miller wrote:
Personally, I think we should use a single version for releasing
our specs. I think this makes it easier for us as developers in
managing spec releases. I think users will find it easier to
collect a consistent set of specifications. I think
In order to make a release you have to touch several files, such as
bumping the versions from 2.0-SNAPSHOT to 2.0-M1 in the poms. IIUC
that is all we need the branch for and can otherwise continue working
on trunk without porting changes back to the branch.
Best wishes,
Paul
On 12/11/06,
On Dec 11, 2006, at 12:16 PM, Dain Sundstrom wrote:
On Dec 11, 2006, at 10:52 AM, Paul McMahan wrote:
I'm in favor of a single version for all specs. Versioning the specs
individually has some advantages but makes the release manager's job
more difficult since the tooling doesn't readily
1 - 100 of 173 matches
Mail list logo
