Re: how are gbean references resolved?

[Conrad O'Dea]

Hi David, 

On Wed, 2006-02-22 at 13:11 -0600, David Jencks wrote:

[snip]
> There's a missing feature at the moment that the web service builder  
> (axis or celtix) does not get to add to the default parents.  In the  
> 1.1/configid branch we are greatly modifying how the default parents  
> are set up and I plan to look at this problem with web service  
> builders after we get 1.1 out.  Meanwhile you will need to change the  
> default parentids in the jetty, tomcat, and openejb builders.

Updating the parentIds did the trick here. Now I have a gbean that I can
deploy to Geronimo and have it handle deployments of POJOs.  This leads
me on to two questions.  

Is is possible to update the parentIds for these modules through the
config.xml?  Right now, to get my Celtix deployer to work I need to
build my own config for G.  It would be great if this could be done by
some quick edits to a config.xml in a binary distribution of G.

The other question is related to a problem I am seeing after the WS POJO
has been deployed and a CeltixWebServiceContainer is constructed.  When
the JettyPOJOWebServiceHolder receives the container, a
ClassCastException is thrown.  This is occurring because the
WebServiceContainer interface implemented by my container has been
loaded through a different class-loader to that used by the Jetty module
(I'm just working with Jetty and POJOs for the minute).

The JettyPOJOWebServiceHolder used this classloader to load the
interface:
[org.apache.geronimo.kernel.config.MultiParentClassLoader
id=geronimo/rmi-naming/1.2-SNAPSHOT/car]
whereas the celtix gbean loaded the interface through this loader:
 [org.apache.geronimo.kernel.config.MultiParentClassLoader
id=geronimo/celtix-deployer/1.2/car]

How do I get the celtix GBean to see the same version
WebServiceContainer as the Jetty and the rest of the of the service.
The deployment plan for my GBean is attached for reference.  I noticed
that the Jetty Gbean has a commented-out parentId reference to
rmi-naming but does not currently have a parent config.

thanks again,
Conrad 





http://geronimo.apache.org/xml/ns/deployment";
configId="geronimo/celtix-deployer/1.2/car"
domain="geronimo.maven"
server="geronimo">

  
  	celtix
celtix-geronimo
0.5-SNAPSHOT
  

  
  	celtix
celtix-api
0.5-SNAPSHOT
  

 

  
  	celtix
jaxb-api
2.0-JAXWS-2.0-EA3
  

  
  	celtix
jaxb-impl
2.0-JAXWS-2.0-EA3
  

  
  	celtix
jaxws-api
2.0-JAXWS-2.0-EA3
  

  
  	celtix
jaxb-impl
2.0-JAXWS-2.0-EA3
  
  

  
  	celtix
jsr173-api
2.0-JAXWS-2.0-EA3
  
  
  
  	celtix
activation
1.0.2
  

  
geronimo
geronimo-j2ee-builder
1.2-SNAPSHOT
  

  
geronimo
geronimo-deployment
1.2-SNAPSHOT
  

  
geronimo
geronimo-webservices
1.2-SNAPSHOT
  

  
  	
  

[jira] Closed: (GERONIMO-1715) derby module migration to Maven2

[Jacek Laskowski (JIRA)]

 [ http://issues.apache.org/jira/browse/GERONIMO-1715?page=all ]
 
Jacek Laskowski closed GERONIMO-1715:
-


Confirmed thus eligible to be closed.

> derby module migration to Maven2
> 
>
>  Key: GERONIMO-1715
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1715
>  Project: Geronimo
> Type: Sub-task
> Reporter: Prasad Kashyap
> Assignee: Jacek Laskowski
>  Fix For: 1.x
>  Attachments: derby.patch
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Created: (GERONIMO-1721) Security Realms portlet should provide link to delete an existing realm

[Vamsavardhana Reddy (JIRA)]

Security Realms portlet should provide link to delete an existing realm
---

 Key: GERONIMO-1721
 URL: http://issues.apache.org/jira/browse/GERONIMO-1721
 Project: Geronimo
Type: Improvement
  Components: console  
Versions: 1.0, 1.1, 1.2
Reporter: Vamsavardhana Reddy
Priority: Minor
 Fix For: 1.2


Security Realms portlet currently provides "edit" and "usage" links against 
existing realms.  It does not provide a link to delete a realm.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: Summary? was: Session API....

[Jules Gosnell]

David Blevins wrote:

Sorry, was referring to this thread.  Seems like it's winding down  
and just looking for a clear idea of what the current thinking is.


Hi David - allow me to wind it up again :-)

I am particularly interested in your thoughts/requirements about a 
Session management API for OpenEJB... You seemed to have remained a 
little quiet on this thread...


Here we go:


Guys,

Firstly, I think a unified Session API is a good thing - it's
something that I have been working towards in WADI for sometime.

Secondly, I have many issues with this one :-)

It may be that I have misunderstood aspects of this API and I am open
to correction where this has happened.

All observations are off the top of my head - since I until I actually
try to put WADI behind this API, I am not going to discover the full
breadth of my problems.

To keep things as simple as possible, I am only going to go for the
big money... I'll make 3 points, then illustrate them.

1)

I would like to see a very clear distinction between what I call the
'Session API' (The API used between the container -
Jetty/Tomcat/OpenEJB etc - and Geronimo, for Session creation,
destruction and retrieval), what Greg is calling the 'Policy' SPI
(The stuff that worries about things like the location of a Session
and whether it is Local or Remote) and what I guess is your current
'Policy' implementation.

I see the successful definition of the 'Session API' component as the
most important of these. The 'Policy SPI' is going to be more
contentious - your current API and implementation seem quite closely
bound and present a number of issues for WADI.

2)

I think that the issue of session colocation should not be exposed in
the 'Session API' component. I see this very much as a pluggable
implementation detail, that is irrelevant to the container using the
API. The implementation behind the API will be in full control of
creation of the Key, the Session, the Session lifecycle and Session
storage. I do not see why you need to expose any detail of your
internal mechanisms to the Session consumer.

3)

I think that you are completely omitting one of the key players from
this API. The Invocation. The goal of successful Session management is
that Invocation and Session should meet somewhere in the cluster for
the successful rendering/processing of a page/rpc/whatever. The
Invocation carries all the information that you may wish to a)
intercept and process elsewhere, b) pass onto the Session management
layer to aid in its decision making upon creation, retrieval and
invalidation of a Session. Depending on how responsibilities are split
between client container and Session manager, the session management
layer may actually want to modify the return values in this
Invocation - adding removing session cookies/attributes, changing ttls
upon this attribute, changing the value of this attribute or altering
other information within the Invocation that is used to integrate it
better with the Client at the other end of the wire. All these
interactions should be opaque to the client-container
(Jetty/TC/OpenEJB/...) and depend entirely on the implementation of
the Client (or e.g. Http loadbalancer) and the session management
layer.

Illustrations :

1). I don't think that the Location of a Session if of any relevance
to the Consumer. Jetty/TC/OpenEJB are simply interested in looking up
a Session and using it. A number of classes in
org.apache.geronimo.session talk in terms of Location. I see Location
as an implementation detail. WADI will have trouble mapping to some of
the assumptions that appear to be made in this part of the
API. e.g. Locator.getSessionLocation() is not an efficient thing to do
in WADI. It involves a round-trip to the owner of this section of the
Location Map. When WADI wants to move a Session it sends a message to
this node, which sends a message to the owner of the Session, which
sends a message containing the Session to the node that made the
request - 3 hops. This API would require a 4-hop trip - 1 rpc (2-hops)
to find the location and one (another 2 hops) to retrieve it. There is
actually a lot more detail involved here (another two hops are
involved in locking/unlocking etc) in which this API would create
further issue. Why bother to describe all implementations when the
Session consumer has no requirement ?

2). I'll call on the KISS principle here. I think that by exposing the
issues of colocation in the API, you are moving complexity from the
implementation into the API. I think the priority should be to keep
the API simple. At the creation of a Session the client container
should pass the necessary information to the Session management impl
so that it can take a decision about how it wishes to represent this
Session. This choice of representation is very implementation specific
and will have consequences for the granularity at which Sessions and
their Attributes may be replicated, serialised, enumerated and
iterated upon. By exposing an

Re: [IDE malarkey] dealing with log4j in your IDE versus Maven

[Guillaume Nodet]

In ServiceMix, i solved the problem by specifying another log4j 
configuration that is used in maven only.


Just add the following lines in the project.properties
 maven.junit.sysproperties=log4j.configuration
 log4j.configuration=log4j-tests.properties

and magically, maven tests will be run using log4j-tests.properties and 
the IDE will use default log4j.properties.


Guillaume


James Strachan wrote:

This might be completely obvious to everyone - but I just thought I'd  
explain what I've just started doing with my IDE and I wished I'd  
done this a long long time ago...


So ActiveMQ uses log4j.properties on the classpath (usually in  
$module/src/test/resources/). By default the logging level is INFO  
and it goes to a log file so that when you run the maven build it  
doesn't fill the screen with lots of garbage. (Incidentally some  
tests are timing sensitive, so setting logging level to DEBUG will  
often cause some tests to fail as debug logging slows things down so  
much)


However when running stuff in your IDE - e.g. working on a specific  
test case or program, you often want output to the console so you see  
it nicely in your IDE. Often you want debug too.


So for the longest time I've been hacking, say, the activemq-core/src/ 
test/resources/log4j.properties file for IDE use to enable stdout /  
DEBUG; then having to remember to switch it back when doing  
subversion commits etc.


I'm sure somewhere there's a great log4j plugin to eclipse that  
actually works well (I've tried a few plugins for IDEs over the years  
and never managed to get them to work well); but as a quick hack I  
created a new project called IDE which just contains stuff to put on  
the classpath when running stuff in your IDE; so added a  
log4j.properties for IDE use. Then I added this as the first  
dependency in the ActiveMQ project and voila - no more hack-revert of  
the log4j.properties in the maven build; I can keep the 2 separate.


Totally trivial and obvious - and I'm sure some ecilpse plugin  
somewhere solves this better - but its well worth doing something  
like this if you hack on the ActiveMQ code a fair bit.


James
---
http://radio.weblogs.com/0112098/

Re: M2 migration status

[Jacek Laskowski]

2006/3/8, Henri Yandell <[EMAIL PROTECTED]>:

> I thought it was going to be an easy fix, adding
> System.getProperty("basedir"), but it doesn't actually use something
> local, it uses the /tmp. So I'm also looking at having it be
> target/dbderby, I'm  not sure why it needs to be in tmp anyway.

I was thinking along these lines, when suddenly Prasad sorted it out
so easy. Check it out and think how easy it was. I'm not sure if it
wasn't me who might've suggested it's something with target. If it's
me, please accept my appologies ;)

> Hen

Jacek

--
Jacek Laskowski
http://www.laskowski.org.pl

Re: [jira] Created: (GERONIMO-1719) GBuild agent JMS reconnect logic is incorrect

[Jacek Laskowski]

2006/3/8, Kevan Miller (JIRA) :
> GBuild agent JMS reconnect logic is incorrect
> -
>
>  Key: GERONIMO-1719
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1719

I thought GBuild has its own JIRA space. Shouldn't it go there?

Jacek

--
Jacek Laskowski
http://www.laskowski.org.pl

[jira] Commented: (GERONIMO-1713) j2ee-builder module migration to Maven2

[Anita Kulshreshtha (JIRA)]

[ 
http://issues.apache.org/jira/browse/GERONIMO-1713?page=comments#action_12369635
 ] 

Anita Kulshreshtha commented on GERONIMO-1713:
--

It works without the tests. The maven.test.skip property is being set in  
pom.xml. Tests need direstory structure created by 
setupEar, setupUnpackedEar etc goals. This can all be done in one big ant task. 
Please keep this issue open until it is done.

> j2ee-builder module migration to Maven2
> ---
>
>  Key: GERONIMO-1713
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1713
>  Project: Geronimo
> Type: Sub-task
> Reporter: Anita Kulshreshtha

>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: svn help

[Jacek Laskowski]

2006/3/9, anita kulshreshtha <[EMAIL PROTECTED]>:
> John,
>I have a similar problem. Some files that I checked
> out from SVN have LF endings on my windows box. When I
> create a patch all the LF lines are shown as '-' and
> the same line are added with CRLFs. The patch becomes
> very hard to read. How can I fix this?

It might be that it's something with my configuration, I guess. I
can't understand why Eclipse formatting changes some of XML files with
the different line endings that the file currently has. So, when I
commit such modified sources, svn complains it can't do that due to
the mixture of line endings in a file. The simple '%s,^M,,g' does the
job very well.

Could you list the files you have line ending issues with?

Is there a command in Maven to fix these line endings problems or
ensure that it doesn't pop up again?

> Anita

Jacek

--
Jacek Laskowski
http://www.laskowski.org.pl

[jira] Updated: (GERONIMO-1686) Servlet 2.5 and JSP 2.1 api jars for JavaEE 5 work

[Bill Dudney (JIRA)]

 [ http://issues.apache.org/jira/browse/GERONIMO-1686?page=all ]

Bill Dudney updated GERONIMO-1686:
--

Attachment: jee5_exp.patch

apply at the root of 
http://svn.apache.org/repos/asf/geronimo/specs/branches/jee5_exp
with 'patch -p0 < ./jee5_exp.patch'

> Servlet 2.5 and JSP 2.1 api jars for JavaEE 5 work
> --
>
>  Key: GERONIMO-1686
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1686
>  Project: Geronimo
> Type: New Feature
> Reporter: Bill Dudney
> Priority: Minor
>  Attachments: jee5_exp.patch
>
> I'm typing in the Servlet 2.5 and JSP 2.1 api's and will post a patch the 
> week of 3/6/06.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (GERONIMO-1686) Servlet 2.5 and JSP 2.1 api jars for JavaEE 5 work

[Bill Dudney (JIRA)]

[ 
http://issues.apache.org/jira/browse/GERONIMO-1686?page=comments#action_12369637
 ] 

Bill Dudney commented on GERONIMO-1686:
---

this is the patch for servlet api, i'll be providing the jsp one shortly

> Servlet 2.5 and JSP 2.1 api jars for JavaEE 5 work
> --
>
>  Key: GERONIMO-1686
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1686
>  Project: Geronimo
> Type: New Feature
> Reporter: Bill Dudney
> Priority: Minor
>  Attachments: jee5_exp.patch
>
> I'm typing in the Servlet 2.5 and JSP 2.1 api's and will post a patch the 
> week of 3/6/06.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: svn help

[anita kulshreshtha]

I have looked at *-builder, deploy-*, axis-*, and
derby modules. Here are the pom.xmls that have LF
endings.
directory
hot-deploy
interceptor
tomcat
activemq-embedded-rar

Thnaks
Anita

--- Jacek Laskowski <[EMAIL PROTECTED]> wrote:

> 2006/3/9, anita kulshreshtha <[EMAIL PROTECTED]>:
> > John,
> >I have a similar problem. Some files that I
> checked
> > out from SVN have LF endings on my windows box.
> When I
> > create a patch all the LF lines are shown as '-'
> and
> > the same line are added with CRLFs. The patch
> becomes
> > very hard to read. How can I fix this?
> 
> It might be that it's something with my
> configuration, I guess. I
> can't understand why Eclipse formatting changes some
> of XML files with
> the different line endings that the file currently
> has. So, when I
> commit such modified sources, svn complains it can't
> do that due to
> the mixture of line endings in a file. The simple
> '%s,^M,,g' does the
> job very well.
> 
> Could you list the files you have line ending issues
> with?
> 
> Is there a command in Maven to fix these line
> endings problems or
> ensure that it doesn't pop up again?
> 
> > Anita
> 
> Jacek
> 
> --
> Jacek Laskowski
> http://www.laskowski.org.pl
> 


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: Performance monitoring

[Hernan Cunico]

Ron,
you can use the sample application *Daytrader* already provided with Geronimo. Daytrader is a 
performance benchmarking application, you can find more details on this app at the following URL:


http://opensource2.atlassian.com/confluence/oss/display/GERONIMO/Day+Trader

If you have Geronimo running, access the Daytrader app and see the online help for configuration 
options.


In addition you can enable collecting statistics via the Web Server Manager portlet, see the 
following article for details.


http://opensource2.atlassian.com/confluence/oss/display/GERONIMO/Administrative+tasks#Administrativetasks-Performancemonitoring

Cheers!
Hernan

Ron Quattlebaum wrote:


Hi.

I just looked over the "Geronimo Performance Baseline" presentation.

Could you share with me what tool(s) you use to monitor key performance 
indicators within Geronimo (e.g., JVM Heap, datasource connection pool 
utilization, web container thread pool utilization, etc)?


Thanks,
Ron

Ron Quattlebaum

Re: Summary?

[Jules Gosnell]

David Blevins wrote:

Sorry, was referring to this thread.  Seems like it's winding down  
and just looking for a clear idea of what the current thinking is.



David,

since you are here - a few SFSB questions...

what provisions does the EJB spec make for timing out of SFSBs, if any ? 
what metadata does this require associated with each session ?

what provisions/requirements over and above these does OpenEJB make/have ?
I seem to remember that SFSBs need notification on 
activation/passivation ? is this correct ? are any other notifications 
required ?
Is it possible for one client to pass the handle of an SFSB to another ? 
Does the spec touch on this ? Does it ever happen ?
Aside from lifecycle management, retrieval and timing out, what other 
requirements might OpenEJB have for SFSB management ?
Are Local SFSBs to be considered Serialisable/Passivatable/Migratable or 
not ?


and finally :

Would it be simple to change OpenEJB to use an SFSB handle that included 
an ID to a 'SuperSession' (Object containing all Session objects 
pertaining to a single client for a given Server) along with an ID to 
particular 'SubSession' (The SFSB itself) within this 'SuperSession', 
instead of whatever scheme you currently use ?


looking forward to some interesting answers...


Jules



-David

On Mar 7, 2006, at 9:36 AM, Dain Sundstrom wrote:


Looks good.

-dain

On Mar 6, 2006, at 12:49 AM, Greg Wilkins wrote:


Dain Sundstrom wrote:

My guess is we're going to need to add an event notification  
system  to
the Session APIs.  What do you think about just crib off of the   
servlet

ones.  I think we could just smash the three session listener
interfaces into something like this:

public interface SessionListener extends Listener {
void valueBound(SessionEvent event);
void valueUnbound(SessionEvent event);
void attributeAdded(SessionEvent event);
void attributeRemoved(SessionEvent event);
void attributeRemoved(SessionEvent event);



I think you mean:
 void attributeReplaced(SessionEvent event);



void valueBound(SessionEvent event);
void valueUnbound(SessionEvent event);
void sessionCreated(SessionEvent event)
void sessionDestroyed(SessionEvent event)
}

public class SessionEvent extends Event {
Session getSession();
String getName();
String getValue();
}

We would bind a listener with a method on the Locator:

void addSessionListener(SessionListener listener);
void removeSessionListener(SessionListener listener);





that would certainly do it - the only change I'd like to see
is that the SessionEvent is


 public class SessionEvent extends Event {
 Session getSession();
 String getName();
 String getOldValue();
 String getNewValue();
 }

As it is confusing for remove and replace what getValue() returns.

Also as the bound/unbound events are actually called on the
value itself, you need both old and new values so you can call
unbind and bind during a replace.

cheers








--
"Open Source is a self-assembling organism. You dangle a piece of
string into a super-saturated solution and a whole operating-system
crystallises out around it."

/**
* Jules Gosnell
* Partner
* Core Developers Network (Europe)
*
*www.coredevelopers.net
*
* Open Source Training & Support.
**/

Sun copyrights and our rights to include certain files in the repo

[Jacek Laskowski]

Hi,

It struck me while I was about to commit Bill's patch
(http://issues.apache.org/jira/browse/GERONIMO-1686). Some files in it
(and in j2ee-schema module, actually), contain

Copyright 2003 Sun Microsystems, Inc., 901 San Antonio
Road, Palo Alto, California 94303, U.S.A. All rights
reserved.

What are the rules to store such files in our repo? Since they're in
our repo, they're ours and I was changing the header of the files in
Bill's patch to reference the ASL 2.0 license, but am not sure if I'm
allowed to. If I'm not, they should not be in our repo, either.

Is there a mistake in my reasoning? ;) Desparately looking for a guidance...

Jacek

--
Jacek Laskowski
http://www.laskowski.org.pl

[jira] Commented: (GERONIMO-1686) Servlet 2.5 and JSP 2.1 api jars for JavaEE 5 work

[Jacek Laskowski (JIRA)]

[ 
http://issues.apache.org/jira/browse/GERONIMO-1686?page=comments#action_12369639
 ] 

Jacek Laskowski commented on GERONIMO-1686:
---

What put me off committing it was the license in 
src/main/resources/javax/servlet/resources/web-app_2_3.dtd. Are we allowed to 
have it in our repo? The module/j2ee-schema contains such files too, so it 
could imply we are, but am not so certain as I wish to. Sent a question to the 
dev mailing list. Awaiting response...

Other (important) notes:
 * Use Rev keyword rather than Revision in the header (run svn propset -R 
svn:keywords 'Rev Date')
 * LICENSE.txt and NOTICE.txt are mandatory
 * Use ASL 2.0 in all of the files (xml's too) - no complaints allowed that the 
other specs miss them too ;)
 * No need to specify settings which are (supposed to be) specified in the 
parent pom (cf. scm). Unless it is already, patch the parent pom

> Servlet 2.5 and JSP 2.1 api jars for JavaEE 5 work
> --
>
>  Key: GERONIMO-1686
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1686
>  Project: Geronimo
> Type: New Feature
> Reporter: Bill Dudney
> Priority: Minor
>  Attachments: jee5_exp.patch
>
> I'm typing in the Servlet 2.5 and JSP 2.1 api's and will post a patch the 
> week of 3/6/06.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Assigned: (GERONIMO-1686) Servlet 2.5 and JSP 2.1 api jars for JavaEE 5 work

[Jeff Genender (JIRA)]

 [ http://issues.apache.org/jira/browse/GERONIMO-1686?page=all ]

Jeff Genender reassigned GERONIMO-1686:
---

Assign To: Jeff Genender

> Servlet 2.5 and JSP 2.1 api jars for JavaEE 5 work
> --
>
>  Key: GERONIMO-1686
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1686
>  Project: Geronimo
> Type: New Feature
> Reporter: Bill Dudney
> Assignee: Jeff Genender
> Priority: Minor
>  Attachments: jee5_exp.patch
>
> I'm typing in the Servlet 2.5 and JSP 2.1 api's and will post a patch the 
> week of 3/6/06.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (GERONIMO-1686) Servlet 2.5 and JSP 2.1 api jars for JavaEE 5 work

[Jeff Genender (JIRA)]

[ 
http://issues.apache.org/jira/browse/GERONIMO-1686?page=comments#action_12369640
 ] 

Jeff Genender commented on GERONIMO-1686:
-

Whoops, I took the assignment without reading what Jacek said...and didn't see 
that he already took a gander at it...

> Servlet 2.5 and JSP 2.1 api jars for JavaEE 5 work
> --
>
>  Key: GERONIMO-1686
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1686
>  Project: Geronimo
> Type: New Feature
> Reporter: Bill Dudney
> Assignee: Jeff Genender
> Priority: Minor
>  Attachments: jee5_exp.patch
>
> I'm typing in the Servlet 2.5 and JSP 2.1 api's and will post a patch the 
> week of 3/6/06.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: Sun copyrights and our rights to include certain files in the repo

[Bill Dudney]

Hi Jacek,

Those files are already in your repo

http://svn.apache.org/repos/asf/geronimo/trunk/modules/j2ee-schema/ 
src/j2ee_1_4schema/jsp_2_0.xsd


I just copied the old schemas/dtd's from the existing geronimo stuff.

TTFN,

-bd-

On Mar 9, 2006, at 7:09 AM, Jacek Laskowski wrote:


Hi,

It struck me while I was about to commit Bill's patch
(http://issues.apache.org/jira/browse/GERONIMO-1686). Some files in it
(and in j2ee-schema module, actually), contain

Copyright 2003 Sun Microsystems, Inc., 901 San Antonio
Road, Palo Alto, California 94303, U.S.A. All rights
reserved.

What are the rules to store such files in our repo? Since they're in
our repo, they're ours and I was changing the header of the files in
Bill's patch to reference the ASL 2.0 license, but am not sure if I'm
allowed to. If I'm not, they should not be in our repo, either.

Is there a mistake in my reasoning? ;) Desparately looking for a  
guidance...


Jacek

--
Jacek Laskowski
http://www.laskowski.org.pl

[jira] Commented: (GERONIMO-1686) Servlet 2.5 and JSP 2.1 api jars for JavaEE 5 work

[Jacek Laskowski (JIRA)]

[ 
http://issues.apache.org/jira/browse/GERONIMO-1686?page=comments#action_12369642
 ] 

Jacek Laskowski commented on GERONIMO-1686:
---

I'm not and was happy to see you working on it due to the issues I described ;)

> Servlet 2.5 and JSP 2.1 api jars for JavaEE 5 work
> --
>
>  Key: GERONIMO-1686
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1686
>  Project: Geronimo
> Type: New Feature
> Reporter: Bill Dudney
> Assignee: Jeff Genender
> Priority: Minor
>  Attachments: jee5_exp.patch
>
> I'm typing in the Servlet 2.5 and JSP 2.1 api's and will post a patch the 
> week of 3/6/06.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: Sun copyrights and our rights to include certain files in the repo

[Bill Dudney]

Hi Jacek,

Dooh! Sent this just before I saw your comments in the JIRA issue.

I'll comment on the missing stuff in the JIRA.

BTW: Thanks for looking at the patch so quickly!


TTFN,

Bill Dudney
MyFaces - myfaces.apache.org


On Mar 9, 2006, at 7:20 AM, Bill Dudney wrote:


Hi Jacek,

Those files are already in your repo

http://svn.apache.org/repos/asf/geronimo/trunk/modules/j2ee-schema/ 
src/j2ee_1_4schema/jsp_2_0.xsd


I just copied the old schemas/dtd's from the existing geronimo stuff.

TTFN,

-bd-

On Mar 9, 2006, at 7:09 AM, Jacek Laskowski wrote:


Hi,

It struck me while I was about to commit Bill's patch
(http://issues.apache.org/jira/browse/GERONIMO-1686). Some files  
in it

(and in j2ee-schema module, actually), contain

Copyright 2003 Sun Microsystems, Inc., 901 San Antonio
Road, Palo Alto, California 94303, U.S.A. All rights
reserved.

What are the rules to store such files in our repo? Since they're in
our repo, they're ours and I was changing the header of the files in
Bill's patch to reference the ASL 2.0 license, but am not sure if I'm
allowed to. If I'm not, they should not be in our repo, either.

Is there a mistake in my reasoning? ;) Desparately looking for a  
guidance...


Jacek

--
Jacek Laskowski
http://www.laskowski.org.pl

[jira] Commented: (GERONIMO-1686) Servlet 2.5 and JSP 2.1 api jars for JavaEE 5 work

[Jeff Genender (JIRA)]

[ 
http://issues.apache.org/jira/browse/GERONIMO-1686?page=comments#action_12369643
 ] 

Jeff Genender commented on GERONIMO-1686:
-

About the ASL 2.0 in the XSDs, I think those need to be verbatim with out 
additionally adding the ASF license to them.  Of many the XSDs I have seen, I 
have not found the ASL 2.0 in them.

Also several of the web-app*.xsd and dtds already included with Geornimo specs 
have the Sun copyright in them.  If it is not legal to use them, then we need 
to do something about all the other specs' use of the dtds and xsds as many of 
them contain the Sun copyright.

We really need an official comment on this.  Perhaps I will bring it up in 
[EMAIL PROTECTED]

> Servlet 2.5 and JSP 2.1 api jars for JavaEE 5 work
> --
>
>  Key: GERONIMO-1686
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1686
>  Project: Geronimo
> Type: New Feature
> Reporter: Bill Dudney
> Assignee: Jeff Genender
> Priority: Minor
>  Attachments: jee5_exp.patch
>
> I'm typing in the Servlet 2.5 and JSP 2.1 api's and will post a patch the 
> week of 3/6/06.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (GERONIMO-1686) Servlet 2.5 and JSP 2.1 api jars for JavaEE 5 work

[Bill Dudney (JIRA)]

[ 
http://issues.apache.org/jira/browse/GERONIMO-1686?page=comments#action_12369644
 ] 

Bill Dudney commented on GERONIMO-1686:
---

Hi Jacek & Jeff,

I'm happy to go back and change Revesion to Rev, I did Revision cause that is 
what was in the other files in this branch.

Forgot LICENSE.txt and NOTICE.txt, will add those in another attachement in a 
second...

I used ASL 2.0 on all files I wrote, others were copied out of the older specs 
(as mentioned in the [EMAIL PROTECTED]) thread so I did not want to change 
them. I'm happy to go back and do so though.

Ah yes the scm settings, copy paste error from parent pom. I'd be glad to nuke 
that from the patch and resubmit.

Let me know.

Thanks,

-bd-

> Servlet 2.5 and JSP 2.1 api jars for JavaEE 5 work
> --
>
>  Key: GERONIMO-1686
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1686
>  Project: Geronimo
> Type: New Feature
> Reporter: Bill Dudney
> Assignee: Jeff Genender
> Priority: Minor
>  Attachments: jee5_exp.patch
>
> I'm typing in the Servlet 2.5 and JSP 2.1 api's and will post a patch the 
> week of 3/6/06.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: Sun copyrights and our rights to include certain files in the repo

[Jeff Genender]

Yeah, I think we need some discussion here and maybe bring this up in
[EMAIL PROTECTED]

Many of the xsds/dtds we use for Geronimo specs seem to have the Sun
copyright in them, and/or are used verbatim from Sun with all comments, etc.

In fact in the JIRA issue, GERONIMO-1686, Jacek pointed out that the
web-app_2_3.dtd that Bill Dudney was submitting as a patch contained the
Sun copyright.  Further examination shows that this DTD is already in
our repos, with ful Sun copyright and all, that comes with the
geronimo-j2ee-schema module. In fact, further search yielded the
following with Sun's copyright attached:

Geronimo
-
web-jsptaglibrary_2_0.xsd (3 matches)
web-app_2_4.xsd (3 matches)
jsp_2_0.xsd (3 matches)
j2ee_web_services_client_1_1.xsd (3 matches)
j2ee_web_services_1_1.xsd (3 matches)
j2ee_jaxrpc_mapping_1_1.xsd (3 matches)
j2ee_1_4.xsd (3 matches)
ejb-jar_2_1.xsd (3 matches)
connector_1_5.xsd (3 matches)
application-client_1_4.xsd (3 matches)
application_1_4.xsd (3 matches)

Geronimo Specs
--
jsp_2_0.xsd
web-jsptaglibrary_2_0.xsd
j2ee_1_4.xsd
j2ee_web_services_1_1.xsd
j2ee_web_services_client_1_1.xsd
web-app_2_3.dtd
web-app_2_4.xsd
web-jsptaglibrary_1_2.dtd
web-jsptaglibrary_2_0.xsd

What is Apache's stance on this and what are the legalities regarding
the use of the copyright in the XSDs and DTDs?

Jeff

Jacek Laskowski wrote:
> Hi,
> 
> It struck me while I was about to commit Bill's patch
> (http://issues.apache.org/jira/browse/GERONIMO-1686). Some files in it
> (and in j2ee-schema module, actually), contain
> 
> Copyright 2003 Sun Microsystems, Inc., 901 San Antonio
> Road, Palo Alto, California 94303, U.S.A. All rights
> reserved.
> 
> What are the rules to store such files in our repo? Since they're in
> our repo, they're ours and I was changing the header of the files in
> Bill's patch to reference the ASL 2.0 license, but am not sure if I'm
> allowed to. If I'm not, they should not be in our repo, either.
> 
> Is there a mistake in my reasoning? ;) Desparately looking for a guidance...
> 
> Jacek
> 
> --
> Jacek Laskowski
> http://www.laskowski.org.pl

Re: [jira] Created: (GERONIMO-1719) GBuild agent JMS reconnect logic is incorrect

[Kevan Miller]

On 3/9/06, Jacek Laskowski <[EMAIL PROTECTED]
> wrote:
2006/3/8, Kevan Miller (JIRA) :> GBuild agent JMS reconnect logic is incorrect
> ->
>  Key: GERONIMO-1719>  URL: http://issues.apache.org/jira/browse/GERONIMO-1719
I thought GBuild has its own JIRA space. Shouldn't it go there?

Thanks Jacek, you're right... I've moved the jira's...
--kevan 

Re: Sun copyrights and our rights to include certain files in the repo

[Bill Stoddard]

Jacek Laskowski wrote:

Hi,

It struck me while I was about to commit Bill's patch
(http://issues.apache.org/jira/browse/GERONIMO-1686). Some files in it
(and in j2ee-schema module, actually), contain

Copyright 2003 Sun Microsystems, Inc., 901 San Antonio
Road, Palo Alto, California 94303, U.S.A. All rights
reserved.

What are the rules to store such files in our repo? Since they're in
our repo, they're ours and I was changing the header of the files in
Bill's patch to reference the ASL 2.0 license, 
but am not sure if I'm

allowed to. If I'm not, they should not be in our repo, either.

Is there a mistake in my reasoning? ;) Desparately looking for a guidance...

Jacek


Jacek,
Don't change the copyright statements. The only time it is acceptable to change copyright statements is when 
the copyright holder has assigned copyright ownership to the ASF.


Bill

Re: M2 migration status

[Prasad Kashyap]

Jacek,

>From the existing top level pom that we now have in the trunk, only 2
modules fail a top down build.  (This is after you apply the patch for
directory http://issues.apache.org/jira/browse/GERONIMO-1717)

The 2 modules having issues  are security and j2ee-schema.

For now, we need to skip tests for security. Is it still correct that
a later surefire plugin or maven releases will fix it for us ?

For the j2ee-schema, we still don't know what the problem is. I had a
conversation with David Jencks last evening, the gist of which can be
seen in the JIRA comments. If nobody is looking at this, I can own
this piece. Anita ? Henri ?

Here's my next concern. For these modules that have migrated to m2, we
should include them in the daily G builds as soon as possible. If we
don't pull out the m1 build artifacts, project.xml and maven.xml from
the migrated modules, then there's a chance that those may get changed
behind our backs while we go forward converting more. There might be a
regression of issues.

Cheers
Prasad.

On 3/9/06, Jacek Laskowski <[EMAIL PROTECTED]> wrote:
> 2006/3/8, Henri Yandell <[EMAIL PROTECTED]>:
>
> > I thought it was going to be an easy fix, adding
> > System.getProperty("basedir"), but it doesn't actually use something
> > local, it uses the /tmp. So I'm also looking at having it be
> > target/dbderby, I'm  not sure why it needs to be in tmp anyway.
>
> I was thinking along these lines, when suddenly Prasad sorted it out
> so easy. Check it out and think how easy it was. I'm not sure if it
> wasn't me who might've suggested it's something with target. If it's
> me, please accept my appologies ;)
>
> > Hen
>
> Jacek
>
> --
> Jacek Laskowski
> http://www.laskowski.org.pl
>

[jira] Commented: (GERONIMO-1693) j2ee-schema module migration to Maven2

[Anita Kulshreshtha (JIRA)]

[ 
http://issues.apache.org/jira/browse/GERONIMO-1693?page=comments#action_12369655
 ] 

Anita Kulshreshtha commented on GERONIMO-1693:
--

The catalogLocation is listed as a TODO item with unknown use... Which means we 
need to modify the xmlbeans-maven- plugin to
accept catalogLocation.
http://mojo.codehaus.org/xmlbeans-maven-plugin/xmlbeans-mojo.html
It does have noJavac option.

> j2ee-schema module migration to Maven2
> --
>
>  Key: GERONIMO-1693
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1693
>  Project: Geronimo
> Type: Sub-task
> Reporter: Anita Kulshreshtha
> Priority: Blocker
>  Attachments: pom.patch
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (GERONIMO-1681) directory module migration to Maven2

[Prasad Kashyap (JIRA)]

[ 
http://issues.apache.org/jira/browse/GERONIMO-1681?page=comments#action_12369656
 ] 

Prasad Kashyap commented on GERONIMO-1681:
--

Sorry. Hadn't seen this JIRA. Saw Anita's note on the devlist and created a new 
JIRA. (Geronimo-1717). 
http://issues.apache.org/jira/browse/GERONIMO-1717

That has the patch to run tests successfully.

This module can now be considered migrated successfully.

> directory module migration to Maven2
> 
>
>  Key: GERONIMO-1681
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1681
>  Project: Geronimo
> Type: Sub-task
> Reporter: reghuram rajakumar vasanthakumari
> Assignee: reghuram rajakumar vasanthakumari
>  Attachments: org.apache.geronimo.directory.RunningTest.patch, pom.xml, 
> pom.xml.patch
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: Sun copyrights and our rights to include certain files in the repo

[Jacek Laskowski]

2006/3/9, Bill Stoddard <[EMAIL PROTECTED]>:

> Don't change the copyright statements. The only time it is acceptable to 
> change copyright statements is when
> the copyright holder has assigned copyright ownership to the ASF.

Has it been assigned? If not, my understanding is that we're not
allowed to store them in the repo, either.

> Bill

Jacek

--
Jacek Laskowski
http://www.laskowski.org.pl

Re: Sun copyrights and our rights to include certain files in the repo

[Bill Stoddard]

Jacek Laskowski wrote:

2006/3/9, Bill Stoddard <[EMAIL PROTECTED]>:


Don't change the copyright statements. The only time it is acceptable to change 
copyright statements is when
the copyright holder has assigned copyright ownership to the ASF.


Has it been assigned? If not, my understanding is that we're not
allowed to store them in the repo, either.



That's the wrong question. ASF repositories contain lots of code for which the ASF is not the copyright owner. 
Whether we are allowed to store code in our repositories depends on the license terms and conditions issued by 
the copyright holder.  What are the T&C's for this code? Do we know?


Bill

[jira] Commented: (GERONIMO-1717) directory module migration to Maven2

[Jacek Laskowski (JIRA)]

[ 
http://issues.apache.org/jira/browse/GERONIMO-1717?page=comments#action_12369661
 ] 

Jacek Laskowski commented on GERONIMO-1717:
---

Committed revision 384541. Thanks Prasad! Anything left to migrate wrt the 
module?

> directory module migration to Maven2
> 
>
>  Key: GERONIMO-1717
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1717
>  Project: Geronimo
> Type: Sub-task
> Reporter: Prasad Kashyap
>  Attachments: directory.patch
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: M2 migration status

[anita kulshreshtha]

comments inlne

--- Prasad Kashyap <[EMAIL PROTECTED]>
wrote:

> Jacek,
> 
> From the existing top level pom that we now have in
> the trunk, only 2
> modules fail a top down build.  (This is after you
> apply the patch for
> directory
> http://issues.apache.org/jira/browse/GERONIMO-1717)
> 
> The 2 modules having issues  are security and
> j2ee-schema.
> 
  The security module requires that no test
kenrnel should be running. This happens if there was a
test failure in the system module, it leaves a running
kernel behind. It also requires the
. 
 j2ee-schema requires a modification to
xmlbeans-maven-plugin (may be there is another way) to
accept catalogLocation. Without this none of the
builders can be expected to work correctly. 

> For now, we need to skip tests for security. Is it
> still correct that
> a later surefire plugin or maven releases will fix
> it for us ?
>
As Jacek said using   
2.1.3-SNAPSHOT for surefire plugin
solved the systemProperties problem. May be it has not
made it to the svn. I have not tested system module
today. It was the cause of most failures 2 days ago.
 
> For the j2ee-schema, we still don't know what the
> problem is. I had a
> conversation with David Jencks last evening, the
> gist of which can be
> seen in the JIRA comments. If nobody is looking at
> this, I can own
> this piece. Anita ? Henri ?
The xmlbeans-maven-plugin needs to be modified to
accept catalogLocation. 
 Ant tasks in j2ee-builder and connector-builder 
module need to be migrated. Currently the tests have
been disabled in pom.xml. Please feel free to pick
one!
:). 

Thanks
Anita 
> 
> Here's my next concern. For these modules that have
> migrated to m2, we
> should include them in the daily G builds as soon as
> possible. If we
> don't pull out the m1 build artifacts, project.xml
> and maven.xml from
> the migrated modules, then there's a chance that
> those may get changed
> behind our backs while we go forward converting
> more. There might be a
> regression of issues.
> 
> Cheers
> Prasad.
> 
> On 3/9/06, Jacek Laskowski <[EMAIL PROTECTED]>
> wrote:
> > 2006/3/8, Henri Yandell <[EMAIL PROTECTED]>:
> >
> > > I thought it was going to be an easy fix, adding
> > > System.getProperty("basedir"), but it doesn't
> actually use something
> > > local, it uses the /tmp. So I'm also looking at
> having it be
> > > target/dbderby, I'm  not sure why it needs to be
> in tmp anyway.
> >
> > I was thinking along these lines, when suddenly
> Prasad sorted it out
> > so easy. Check it out and think how easy it was.
> I'm not sure if it
> > wasn't me who might've suggested it's something
> with target. If it's
> > me, please accept my appologies ;)
> >
> > > Hen
> >
> > Jacek
> >
> > --
> > Jacek Laskowski
> > http://www.laskowski.org.pl
> >
> 


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: M2 migration status

[Joe Bohn]

Prasad Kashyap wrote:


Here's my next concern. For these modules that have migrated to m2, we
should include them in the daily G builds as soon as possible. If we
don't pull out the m1 build artifacts, project.xml and maven.xml from
the migrated modules, then there's a chance that those may get changed
behind our backs while we go forward converting more. There might be a
regression of issues.


I have the same concern and voiced it (from the other direction) in my 
post on little-G.


We also need to ensure that when we clearly communicate what version(s) 
of maven are required to build Geronimo, the updated build process, and 
be aware of the waiting changes that may be impacted before we actually 
start yanking things.


To accomplish that last goal we need some way to communicate changes 
that are waiting or in-progress which may affect or be affected by the 
M2 conversion.  Then we can work together more closely to ensure that 
nothing is lost during the conversion.  I will add comments to the M2 
migration status list with a reference to the little-G JIRA for items 
where I am aware of overlap.  Can others please do the same for items 
they are involved in?


Thanks,
Joe

--
Joe Bohn
joe.bohn at earthlink.net

"He is no fool who gives what he cannot keep, to gain what he cannot 
lose."   -- Jim Elliot

Re: littleG (minimal-tomcat-server) status

[Jeff Genender]

Hey Joe,

Which patch is the most up-to-date one to use?

Jeff

Joe Bohn wrote:
> Thank you Jeff.
> 
> Please note that as you look at GERONIMO-1613, (
> http://issues.apache.org/jira/browse/GERONIMO-1613 )
> the only patch you should need to apply is the latest one 
> 1613_RemoveDeps4.patch.   This is all inclusive of the other patches
> with the exception of the first patch that Dave Jencks already
> integrated a few weeks back.
> 
> BTW, there are also two JIRAs for some problems that I noticed were
> introduced as a result of the first patch (sigh)    GERONIMO-1634 (
> https://issues.apache.org/jira/browse/GERONIMO-1634 ) and GERONIMO-1699
> ( https://issues.apache.org/jira/browse/GERONIMO-1699 ).
> 
> Joe
> 
> 
> Jeff Genender wrote:
>> Hi Joe,
>>
>> Thanks for working on this...I'll take a look.
>>
>> Jeff
>>
>> Joe Bohn wrote:
>>
>>> I'd really like to get a committer to look into these changes and
>>> hopefully commit them fairly quickly.
>>>
>>> David J ... I know that you're tied up with the configID changes.  Is
>>> there somebody else that could take a quick look at these changes?
>>>
>>> I'm concerned that the current activity to convert from M1 to M2 might
>>> result in some of these changes being lost in the conversion.  For
>>> example, the patch includes a change to the tomcat module which I see is
>>> being actively converted to M2.
>>>
>>> I should note that these changes are a bit risky and will possibly cause
>>> some NoClassDefFoundErrors on specific scenarios when integrated.  I
>>> have done the following tests for both the jetty and tomcat assemblies
>>> but I obviously can't cover everything.  1) Verified the itests are
>>> successful.  2) Verified that deployment of a web app works  3) Verified
>>> that the main console portlets still function (all main GUIs presented
>>> without error and some detailed functions verified)  4) Verified that
>>> all of the daytrader application web primitives continued to work.At
>>> this point it might be best to integrate the changes and deal with the
>>> fall-out.  Thoughts?
>>>
>>> Thanks,
>>> Joe
>>>
>>> Joe Bohn wrote:
>>>
 Ah ... thanks for the clarification Kevan.   In that case I don't
 think it is needed in rmi-naming with the uber-spec removed.   I
 couldn't find any reason to include the corba spec in the rmi-naming
 config.   I've created a new patch with this change and added it to
 GERONIMO-1613.

 So, with the corba spec removed our image size is back down to about
 15.7 meg.

 Thanks,
 Joe


 Kevan Miller wrote:


>
> On 3/3/06, *Joe Bohn* <[EMAIL PROTECTED]
> > wrote:
>
>
>I just added an updated patch to Geronimo-1613
>https://issues.apache.org/jira/browse/GERONIMO-1613
>
>After some painstaking effort, I was finally able to remove the
>uber-spec dependency from rmi-naming which should have resulted
> in an
>additional savings in little-G of nearly 1.2 meg. 
> Unfortunately, I had
>to add in some individual spec jars that were not previously
> included
>and which decreased the savings somewhat.
>
>The real disappointment was when I picked up the latest image
> yesterday
>to create the patch and noticed Kevan's change to include the
> CORBA spec
>in rmi-naming to work around some other problem.  This adds back in
>about 640K.  The comment indicates that this is only temporary. 
> How
>long will it be needed there and is somebody working to remove it?
>
>
> Hi Joe,
> If you've removed the uber-jar, then you should be able to remove the
> CORBA spec jar (assuming you're including the CORBA spec jar at an
> appropriate location...). The uber-jar currently contains bad corba
> spec classes. The dependency in rmi-naming put the CORBA spec jar in
> the classpath in front of the uber-jar. I also plan on fixing the
> uber-jar (getting the proper spec classes in the uber-jar).
>
> --kevan
>
>So, after all that the latest patch only takes us from 16.4 to
> about
>16.3 meg ... but we'll drop more when CORBA comes out of
> rmi-naming.
>
>Would it be possible to get this patch committed to trunk before
> too
>much more work happens on the maven2 effort?  I think that it would
>benefit the migration and integration if these updated project.xmls
>were
>used as the starting point.
>
>Joe
>
>
>--
>Joe Bohn
>joe.bohn at earthlink.net 
>
>"He is no fool who gives what he cannot keep, to gain what he
> cannot
>lose."   -- Jim Elliot
>
>

>>
>>
> 

[jira] Assigned: (GERONIMO-1613) Eliminate unncessary dependencies to reduce assemnbly footprint size

[Jeff Genender (JIRA)]

 [ http://issues.apache.org/jira/browse/GERONIMO-1613?page=all ]

Jeff Genender reassigned GERONIMO-1613:
---

Assign To: Jeff Genender  (was: David Jencks)

> Eliminate unncessary dependencies to reduce assemnbly footprint size
> 
>
>  Key: GERONIMO-1613
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1613
>  Project: Geronimo
> Type: Improvement
>   Components: general
> Versions: 1.2
>  Environment: all
> Reporter: Joe Bohn
> Assignee: Jeff Genender
>  Fix For: 1.2
>  Attachments: 1613_RemoveDeps3.patch, 1613_RemoveDeps4.patch, 
> RemoveDeps.patch, RemoveDeps2.1.patch, RemoveDeps2.2.patch, 
> RemoveDeps2.3.patch, RemoveDeps2.patch
>
> Clean up assembly project.xml and eliminate some unnecessary dependencies in 
> various modules and configs.  This will reduce the footprint size (with 
> special attention to the minimal-tomcat-assembly.
> The patch contains the following:
> - clean up minimal-tomcat-server\project.xml to remove commented out sections
> - clean up web-jms-tomcat-server\project.xml to remove commented out sections
> - remove dependencies from config\j2ee_server on xstream, jaxr-api, and 
> geronimo-derby
> - remove dependencies from config\j2ee_deployer on geronimo-client-builder
> - remove dependencies from module\tomcat on activecluster, wadi-core, and 
> wadi-tomcat55
> There are still more dependencies that should be removed but this is a start.
> These changes reduce the disk footprint of minimal-tomcat-server from 27 meg 
> to about 21 meg.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Created: (SM-344) Improve clustering by allowing implicit endpoint selection to be done by the flow

[Guillaume Nodet (JIRA)]

Improve clustering by allowing implicit endpoint selection to be done by the 
flow
-

 Key: SM-344
 URL: http://jira.activemq.org/jira//browse/SM-344
 Project: ServiceMix
Type: Improvement

  Components: servicemix-core  
Reporter: Guillaume Nodet
 Fix For: 3.0-M2


We should create one queue per interface and service,
so that the load-balancing would be more effective
when targeting an interface.

This will require to move the endpoint resolution to the 
flows instead of the broker.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.activemq.org/jira//secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: Sun copyrights and our rights to include certain files in the repo

[Geir Magnusson Jr]

Exactly the right question - the copyright isn't the issue, but the 
license is.


Where did these schemas come from, and what are the listed terms?

geir

Bill Stoddard wrote:

Jacek Laskowski wrote:

2006/3/9, Bill Stoddard <[EMAIL PROTECTED]>:

Don't change the copyright statements. The only time it is acceptable 
to change copyright statements is when

the copyright holder has assigned copyright ownership to the ASF.


Has it been assigned? If not, my understanding is that we're not
allowed to store them in the repo, either.



That's the wrong question. ASF repositories contain lots of code for 
which the ASF is not the copyright owner. Whether we are allowed to 
store code in our repositories depends on the license terms and 
conditions issued by the copyright holder.  What are the T&C's for this 
code? Do we know?


Bill

[jira] Resolved: (SM-149) Clustering should be done per endpoint instead of per component

[Guillaume Nodet (JIRA)]

 [ http://jira.activemq.org/jira//browse/SM-149?page=all ]
 
Guillaume Nodet resolved SM-149:


 Resolution: Fixed
Fix Version: (was: 3.0)
 3.0-M1

> Clustering should be done per endpoint instead of per component
> ---
>
>  Key: SM-149
>  URL: http://jira.activemq.org/jira//browse/SM-149
>  Project: ServiceMix
> Type: Improvement

>   Components: servicemix-core
> Reporter: Guillaume Nodet
> Assignee: Guillaume Nodet
>  Fix For: 3.0-M1

>
>
> Clustering is currently effective on a per component basis.
> But this should be done per endpoint, because one service unit may not be 
> deployed on all components of the cluster.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.activemq.org/jira//secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: M2 migration status

[anita kulshreshtha]

--- Joe Bohn <[EMAIL PROTECTED]> wrote:

> 
> Prasad Kashyap wrote:
> 
> > Here's my next concern. For these modules that
> have migrated to m2, we
> > should include them in the daily G builds as soon
> as possible. If we
> > don't pull out the m1 build artifacts, project.xml
> and maven.xml from
> > the migrated modules, then there's a chance that
> those may get changed
> > behind our backs while we go forward converting
> more. There might be a
> > regression of issues.
I am in favor of running parallel builds until all
the modules can be built even by skipping the tests.
Then we need to go through the dependencies and change
their scopes (compile/test/runtime) and see how m2
handles it. I do not think maven.xmls are being
modified , please correct me if I am wrong. People
modifying project.xml chould make a note in the jira
that the dependency list has been modified. Though if
we do the scope thing right, we should end up with the
same list... Well that is my impression...

Thanks
Anita
> 
> I have the same concern and voiced it (from the
> other direction) in my 
> post on little-G.
> 
> We also need to ensure that when we clearly
> communicate what version(s) 
> of maven are required to build Geronimo, the updated
> build process, and 
> be aware of the waiting changes that may be impacted
> before we actually 
> start yanking things.
> 
> To accomplish that last goal we need some way to
> communicate changes 
> that are waiting or in-progress which may affect or
> be affected by the 
> M2 conversion.  Then we can work together more
> closely to ensure that 
> nothing is lost during the conversion.  I will add
> comments to the M2 
> migration status list with a reference to the
> little-G JIRA for items 
> where I am aware of overlap.  Can others please do
> the same for items 
> they are involved in?
> 
> Thanks,
> Joe
> 
> -- 
> Joe Bohn
> joe.bohn at earthlink.net
> 
> "He is no fool who gives what he cannot keep, to
> gain what he cannot 
> lose."   -- Jim Elliot
> 


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: Sun copyrights and our rights to include certain files in the repo

[Jeff Genender]

Here is what it says in the DTD:

"This document and the product to which it pertains are distributed
under licenses restricting their use, copying, distribution, and
decompilation.  This document may be reproduced and distributed but may
not be changed without prior written authorization of Sun and its
licensors, if any."

So, from this blurb, it would appear we can include the DTDs and XSDs,
but we *cannot* change it.  Would this be a correct assessment?

Jeff

Geir Magnusson Jr wrote:
> Exactly the right question - the copyright isn't the issue, but the
> license is.
> 
> Where did these schemas come from, and what are the listed terms?
> 
> geir
> 
> Bill Stoddard wrote:
>> Jacek Laskowski wrote:
>>> 2006/3/9, Bill Stoddard <[EMAIL PROTECTED]>:
>>>
 Don't change the copyright statements. The only time it is
 acceptable to change copyright statements is when
 the copyright holder has assigned copyright ownership to the ASF.
>>>
>>> Has it been assigned? If not, my understanding is that we're not
>>> allowed to store them in the repo, either.
>>>
>>
>> That's the wrong question. ASF repositories contain lots of code for
>> which the ASF is not the copyright owner. Whether we are allowed to
>> store code in our repositories depends on the license terms and
>> conditions issued by the copyright holder.  What are the T&C's for
>> this code? Do we know?
>>
>> Bill
>>
>>

Re: M2 migration status

[Jacek Laskowski]

2006/3/9, Prasad Kashyap <[EMAIL PROTECTED]>:

> From the existing top level pom that we now have in the trunk, only 2
> modules fail a top down build.  (This is after you apply the patch for
> directory http://issues.apache.org/jira/browse/GERONIMO-1717)

Committed as revision 384541. Must've missed it.

> The 2 modules having issues  are security and j2ee-schema.

What issues are you seeing in the security module? Just double-checked
it and it worked for me (be it executed in its own directory or in the
top-level directory with maven-surefire-plugin directory renamed in
the m2 local repo).

> For now, we need to skip tests for security. Is it still correct that
> a later surefire plugin or maven releases will fix it for us ?

Are you working with the latest sources? It seems you're not.

> For the j2ee-schema, we still don't know what the problem is. I had a
> conversation with David Jencks last evening, the gist of which can be
> seen in the JIRA comments. If nobody is looking at this, I can own
> this piece. Anita ? Henri ?

If you don't mind, go ahead (unless they're working on it).

> Here's my next concern. For these modules that have migrated to m2, we
> should include them in the daily G builds as soon as possible. If we
> don't pull out the m1 build artifacts, project.xml and maven.xml from
> the migrated modules, then there's a chance that those may get changed
> behind our backs while we go forward converting more. There might be a
> regression of issues.

Do you have an idea as to how to achieve it? GBuild? Never worked with
it and although Dave did a great job of documenting it, which might've
made it a simple tool, I won't be able to delve into it soon. Anyone
willing to jump in and take it over? Excellent chance to participate.

> Prasad.

Jacek

--
Jacek Laskowski
http://www.laskowski.org.pl

[jira] Commented: (GERONIMO-1613) Eliminate unncessary dependencies to reduce assemnbly footprint size

[Alan Cabrera (JIRA)]

[ 
http://issues.apache.org/jira/browse/GERONIMO-1613?page=comments#action_12369666
 ] 

Alan Cabrera commented on GERONIMO-1613:


How is all this great work dovetailing with our M2 conversion effort?

> Eliminate unncessary dependencies to reduce assemnbly footprint size
> 
>
>  Key: GERONIMO-1613
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1613
>  Project: Geronimo
> Type: Improvement
>   Components: general
> Versions: 1.2
>  Environment: all
> Reporter: Joe Bohn
> Assignee: Jeff Genender
>  Fix For: 1.2
>  Attachments: 1613_RemoveDeps3.patch, 1613_RemoveDeps4.patch, 
> RemoveDeps.patch, RemoveDeps2.1.patch, RemoveDeps2.2.patch, 
> RemoveDeps2.3.patch, RemoveDeps2.patch
>
> Clean up assembly project.xml and eliminate some unnecessary dependencies in 
> various modules and configs.  This will reduce the footprint size (with 
> special attention to the minimal-tomcat-assembly.
> The patch contains the following:
> - clean up minimal-tomcat-server\project.xml to remove commented out sections
> - clean up web-jms-tomcat-server\project.xml to remove commented out sections
> - remove dependencies from config\j2ee_server on xstream, jaxr-api, and 
> geronimo-derby
> - remove dependencies from config\j2ee_deployer on geronimo-client-builder
> - remove dependencies from module\tomcat on activecluster, wadi-core, and 
> wadi-tomcat55
> There are still more dependencies that should be removed but this is a start.
> These changes reduce the disk footprint of minimal-tomcat-server from 27 meg 
> to about 21 meg.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Closed: (GERONIMO-1681) directory module migration to Maven2

[Jacek Laskowski (JIRA)]

 [ http://issues.apache.org/jira/browse/GERONIMO-1681?page=all ]
 
Jacek Laskowski closed GERONIMO-1681:
-

Fix Version: 1.x
 Resolution: Fixed

Verified thus eligibled to be closed. Thanks Prasad and Reghu!

> directory module migration to Maven2
> 
>
>  Key: GERONIMO-1681
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1681
>  Project: Geronimo
> Type: Sub-task
> Reporter: reghuram rajakumar vasanthakumari
> Assignee: reghuram rajakumar vasanthakumari
>  Fix For: 1.x
>  Attachments: org.apache.geronimo.directory.RunningTest.patch, pom.xml, 
> pom.xml.patch
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: svn commit: r384216 - in /geronimo/daytrader/trunk/modules/web: pom.xml src/main/webapp/WEB-INF/classes/build.properties src/main/webapp/WEB-INF/web.xml

[Jacek Laskowski]

2006/3/8, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
> Author: hogstrom
> Date: Wed Mar  8 05:57:56 2006
> New Revision: 384216
>
> URL: http://svn.apache.org/viewcvs?rev=384216&view=rev
...
> - 
> daytrader-ejb-${pom.currentVersion}.jar#TradeBrokerQueue
> + 
> daytrader-ejb-1.1-SNAPSHOT.jar#TradeBrokerQueue
...
> - 
> daytrader-ejb-${pom.currentVersion}.jar#TradeStreamerTopic
> + 
> daytrader-ejb-1.1-SNAPSHOT.jar#TradeStreamerTopic

What's wrong with the previous "decoupled" solution? Now, everytime
you'll change the version, the file will require it, too. There must
be something in-between and can't see it ;)

Jacek

--
Jacek Laskowski
http://www.laskowski.org.pl

[jira] Closed: (GERONIMO-1672) Migrate security module to M2

[Jacek Laskowski (JIRA)]

 [ http://issues.apache.org/jira/browse/GERONIMO-1672?page=all ]
 
Jacek Laskowski closed GERONIMO-1672:
-

Resolution: Fixed

Whoohoo, another module migrated! Thanks Anita!

> Migrate security module to M2
> -
>
>  Key: GERONIMO-1672
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1672
>  Project: Geronimo
> Type: Task
>   Components: security
> Versions: 1.x
>  Environment: All
> Reporter: Anita Kulshreshtha
> Assignee: Anita Kulshreshtha
>  Fix For: 1.x
>  Attachments: pom.patch
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: M2 migration status

[Joe Bohn]

One other thing.  Most of my changes for little-G 
https://issues.apache.org/jira/browse/GERONIMO-1613 were in the 
configurations rather than the modules.  These aren't yet included in 
the list of "things to be migrated".


I've updated the Migration Status page to include lists for the configs 
and assemblies.


Joe



Joe Bohn wrote:


Prasad Kashyap wrote:


Here's my next concern. For these modules that have migrated to m2, we
should include them in the daily G builds as soon as possible. If we
don't pull out the m1 build artifacts, project.xml and maven.xml from
the migrated modules, then there's a chance that those may get changed
behind our backs while we go forward converting more. There might be a
regression of issues.



I have the same concern and voiced it (from the other direction) in my 
post on little-G.


We also need to ensure that when we clearly communicate what version(s) 
of maven are required to build Geronimo, the updated build process, and 
be aware of the waiting changes that may be impacted before we actually 
start yanking things.


To accomplish that last goal we need some way to communicate changes 
that are waiting or in-progress which may affect or be affected by the 
M2 conversion.  Then we can work together more closely to ensure that 
nothing is lost during the conversion.  I will add comments to the M2 
migration status list with a reference to the little-G JIRA for items 
where I am aware of overlap.  Can others please do the same for items 
they are involved in?


Thanks,
Joe



--
Joe Bohn
joe.bohn at earthlink.net

"He is no fool who gives what he cannot keep, to gain what he cannot 
lose."   -- Jim Elliot

Re: svn help

[anita kulshreshtha]

   I would like to resubmit the patch (remove
reference to 'target' and 'm2' repo) for tomcat as
soon as this is fixed. After that tomcat migration
issue can be closed.

Thanks
Anita

--- anita kulshreshtha <[EMAIL PROTECTED]> wrote:

> I have looked at *-builder, deploy-*, axis-*, and
> derby modules. Here are the pom.xmls that have LF
> endings.
> directory
> hot-deploy
> interceptor
> tomcat
> activemq-embedded-rar
> 
> Thnaks
> Anita
> 
> --- Jacek Laskowski <[EMAIL PROTECTED]> wrote:
> 
> > 2006/3/9, anita kulshreshtha
> <[EMAIL PROTECTED]>:
> > > John,
> > >I have a similar problem. Some files that I
> > checked
> > > out from SVN have LF endings on my windows box.
> > When I
> > > create a patch all the LF lines are shown as '-'
> > and
> > > the same line are added with CRLFs. The patch
> > becomes
> > > very hard to read. How can I fix this?
> > 
> > It might be that it's something with my
> > configuration, I guess. I
> > can't understand why Eclipse formatting changes
> some
> > of XML files with
> > the different line endings that the file currently
> > has. So, when I
> > commit such modified sources, svn complains it
> can't
> > do that due to
> > the mixture of line endings in a file. The simple
> > '%s,^M,,g' does the
> > job very well.
> > 
> > Could you list the files you have line ending
> issues
> > with?
> > 
> > Is there a command in Maven to fix these line
> > endings problems or
> > ensure that it doesn't pop up again?
> > 
> > > Anita
> > 
> > Jacek
> > 
> > --
> > Jacek Laskowski
> > http://www.laskowski.org.pl
> > 
> 
> 
> __
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam
> protection around 
> http://mail.yahoo.com 
> 


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: how are gbean references resolved?

[David Jencks]

On Mar 9, 2006, at 2:53 AM, Conrad O'Dea wrote:


Hi David,

On Wed, 2006-02-22 at 13:11 -0600, David Jencks wrote:

[snip]

There's a missing feature at the moment that the web service builder
(axis or celtix) does not get to add to the default parents.  In the
1.1/configid branch we are greatly modifying how the default parents
are set up and I plan to look at this problem with web service
builders after we get 1.1 out.  Meanwhile you will need to change the
default parentids in the jetty, tomcat, and openejb builders.


Updating the parentIds did the trick here. Now I have a gbean that  
I can
deploy to Geronimo and have it handle deployments of POJOs.  This  
leads

me on to two questions.

Is is possible to update the parentIds for these modules through the
config.xml?  Right now, to get my Celtix deployer to work I need to
build my own config for G.  It would be great if this could be done by
some quick edits to a config.xml in a binary distribution of G.


You can set the defaultParentId for the existing jetty/tomcat/openejb  
builders in config.xml, you just use a comma-delimited list of  
configids like this:





geronimo/jetty/$ 
{geronimo_version}/car,geronimo/j2ee-server/${geronimo_version}/ 
car,geronimo-cts/server-security/${pom.currentVersion}/car



(you probably need to resolve the ${...} to actual versions )


The other question is related to a problem I am seeing after the WS  
POJO
has been deployed and a CeltixWebServiceContainer is constructed.   
When

the JettyPOJOWebServiceHolder receives the container, a
ClassCastException is thrown.  This is occurring because the
WebServiceContainer interface implemented by my container has been
loaded through a different class-loader to that used by the Jetty  
module

(I'm just working with Jetty and POJOs for the minute).

The JettyPOJOWebServiceHolder used this classloader to load the
interface:
[org.apache.geronimo.kernel.config.MultiParentClassLoader
id=geronimo/rmi-naming/1.2-SNAPSHOT/car]
whereas the celtix gbean loaded the interface through this loader:
 [org.apache.geronimo.kernel.config.MultiParentClassLoader
id=geronimo/celtix-deployer/1.2/car]

How do I get the celtix GBean to see the same version
WebServiceContainer as the Jetty and the rest of the of the service.
The deployment plan for my GBean is attached for reference.  I noticed
that the Jetty Gbean has a commented-out parentId reference to
rmi-naming but does not currently have a parent config.


Actually it does :-)  In an effort to reduce duplication most of the  
classloader information for a configuration is derived from the  
project.xml for that module.  In particular the jetty module has two  
parents:




geronimo
rmi-naming
${geronimo_version}
car

 true
 


geronimo
geronimo-jetty
${geronimo_version}

 true
 


The packaging plugin modifies the plan to include these.  If you look  
at the plan in the target directory of a config you will see the  
final plan that is actually used.


If you are using the packaging plugin to build your config you can  
use this technique, otherwise you need to include the parents as  
imports directly in your plan.  In either case including the rmi- 
naming config as an import should solve the duplicate classloader  
problem.


thanks
david jencks



thanks again,
Conrad

[jira] Assigned: (GERONIMO-1706) j2ee module migration to Maven2

[Anita Kulshreshtha (JIRA)]

 [ http://issues.apache.org/jira/browse/GERONIMO-1706?page=all ]

Anita Kulshreshtha reassigned GERONIMO-1706:


Assign To: Anita Kulshreshtha

The test failures were due to a kernel left behind by test failures in the 
system module.
This issue can be closed now. 

> j2ee module migration to Maven2
> ---
>
>  Key: GERONIMO-1706
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1706
>  Project: Geronimo
> Type: Sub-task
> Reporter: Anita Kulshreshtha
> Assignee: Anita Kulshreshtha

>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (GERONIMO-1672) Migrate security module to M2

[Anita Kulshreshtha (JIRA)]

[ 
http://issues.apache.org/jira/browse/GERONIMO-1672?page=comments#action_12369669
 ] 

Anita Kulshreshtha commented on GERONIMO-1672:
--

There were two causes of test failures :
  1. A 'test kernel' left running by test failures in an earlier module/build.
   2. Making systemProperties available to surefire plugin. Using 
2.1.3-SNAPSHOT version of surefire plugin
This issue can now be closed.

> Migrate security module to M2
> -
>
>  Key: GERONIMO-1672
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1672
>  Project: Geronimo
> Type: Task
>   Components: security
> Versions: 1.x
>  Environment: All
> Reporter: Anita Kulshreshtha
> Assignee: Anita Kulshreshtha
>  Fix For: 1.x
>  Attachments: pom.patch
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Created: (GERONIMO-1722) activemq-embedded-rar module migration to Maven 2

[Jacek Laskowski (JIRA)]

activemq-embedded-rar module migration to Maven 2
-

 Key: GERONIMO-1722
 URL: http://issues.apache.org/jira/browse/GERONIMO-1722
 Project: Geronimo
Type: Sub-task
  Components: ActiveMQ  
Versions: 1.x
Reporter: Jacek Laskowski


It's a task to help keep track of the progress of the module build migration to 
Maven2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (GERONIMO-1722) activemq-embedded-rar module migration to Maven 2

[Jacek Laskowski (JIRA)]

[ 
http://issues.apache.org/jira/browse/GERONIMO-1722?page=comments#action_12369678
 ] 

Jacek Laskowski commented on GERONIMO-1722:
---

It's almost there, but maven-rar-plugin adds all the dependencies to the rar, 
which it shouldn't.

> activemq-embedded-rar module migration to Maven 2
> -
>
>  Key: GERONIMO-1722
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1722
>  Project: Geronimo
> Type: Sub-task
>   Components: ActiveMQ
> Versions: 1.x
> Reporter: Jacek Laskowski

>
> It's a task to help keep track of the progress of the module build migration 
> to Maven2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: littleG (minimal-tomcat-server) status

[Joe Bohn]

1613_RemoveDeps4.patch

Jeff Genender wrote:

Hey Joe,

Which patch is the most up-to-date one to use?

Jeff

Joe Bohn wrote:


Thank you Jeff.

Please note that as you look at GERONIMO-1613, (
http://issues.apache.org/jira/browse/GERONIMO-1613 )
the only patch you should need to apply is the latest one 
1613_RemoveDeps4.patch.   This is all inclusive of the other patches
with the exception of the first patch that Dave Jencks already
integrated a few weeks back.

BTW, there are also two JIRAs for some problems that I noticed were
introduced as a result of the first patch (sigh)    GERONIMO-1634 (
https://issues.apache.org/jira/browse/GERONIMO-1634 ) and GERONIMO-1699
( https://issues.apache.org/jira/browse/GERONIMO-1699 ).

Joe


Jeff Genender wrote:


Hi Joe,

Thanks for working on this...I'll take a look.

Jeff

Joe Bohn wrote:



I'd really like to get a committer to look into these changes and
hopefully commit them fairly quickly.

David J ... I know that you're tied up with the configID changes.  Is
there somebody else that could take a quick look at these changes?

I'm concerned that the current activity to convert from M1 to M2 might
result in some of these changes being lost in the conversion.  For
example, the patch includes a change to the tomcat module which I see is
being actively converted to M2.

I should note that these changes are a bit risky and will possibly cause
some NoClassDefFoundErrors on specific scenarios when integrated.  I
have done the following tests for both the jetty and tomcat assemblies
but I obviously can't cover everything.  1) Verified the itests are
successful.  2) Verified that deployment of a web app works  3) Verified
that the main console portlets still function (all main GUIs presented
without error and some detailed functions verified)  4) Verified that
all of the daytrader application web primitives continued to work.At
this point it might be best to integrate the changes and deal with the
fall-out.  Thoughts?

Thanks,
Joe

Joe Bohn wrote:



Ah ... thanks for the clarification Kevan.   In that case I don't
think it is needed in rmi-naming with the uber-spec removed.   I
couldn't find any reason to include the corba spec in the rmi-naming
config.   I've created a new patch with this change and added it to
GERONIMO-1613.

So, with the corba spec removed our image size is back down to about
15.7 meg.

Thanks,
Joe


Kevan Miller wrote:




On 3/3/06, *Joe Bohn* <[EMAIL PROTECTED]
> wrote:


  I just added an updated patch to Geronimo-1613
  https://issues.apache.org/jira/browse/GERONIMO-1613

  After some painstaking effort, I was finally able to remove the
  uber-spec dependency from rmi-naming which should have resulted
in an
  additional savings in little-G of nearly 1.2 meg. 
Unfortunately, I had

  to add in some individual spec jars that were not previously
included
  and which decreased the savings somewhat.

  The real disappointment was when I picked up the latest image
yesterday
  to create the patch and noticed Kevan's change to include the
CORBA spec
  in rmi-naming to work around some other problem.  This adds back in
  about 640K.  The comment indicates that this is only temporary. 
How

  long will it be needed there and is somebody working to remove it?


Hi Joe,
If you've removed the uber-jar, then you should be able to remove the
CORBA spec jar (assuming you're including the CORBA spec jar at an
appropriate location...). The uber-jar currently contains bad corba
spec classes. The dependency in rmi-naming put the CORBA spec jar in
the classpath in front of the uber-jar. I also plan on fixing the
uber-jar (getting the proper spec classes in the uber-jar).

--kevan

  So, after all that the latest patch only takes us from 16.4 to
about
  16.3 meg ... but we'll drop more when CORBA comes out of
rmi-naming.

  Would it be possible to get this patch committed to trunk before
too
  much more work happens on the maven2 effort?  I think that it would
  benefit the migration and integration if these updated project.xmls
  were
  used as the starting point.

  Joe


  --
  Joe Bohn
  joe.bohn at earthlink.net 

  "He is no fool who gives what he cannot keep, to gain what he
cannot
  lose."   -- Jim Elliot











--
Joe Bohn
joe.bohn at earthlink.net

"He is no fool who gives what he cannot keep, to gain what he cannot 
lose."   -- Jim Elliot

[jira] Created: (GERONIMO-1723) Module migration to Maven 2: axis-builder

[Jacek Laskowski (JIRA)]

Module migration to Maven 2: axis-builder
-

 Key: GERONIMO-1723
 URL: http://issues.apache.org/jira/browse/GERONIMO-1723
 Project: Geronimo
Type: Sub-task
  Components: webservices  
Reporter: Jacek Laskowski
 Fix For: 1.x


It's a task to help keep track of the progress of the module build migration to 
Maven2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Created: (GERONIMO-1724) Module migration to Maven 2: client

[Jacek Laskowski (JIRA)]

Module migration to Maven 2: client
---

 Key: GERONIMO-1724
 URL: http://issues.apache.org/jira/browse/GERONIMO-1724
 Project: Geronimo
Type: Sub-task
Versions: 1.x
Reporter: Jacek Laskowski


It's a task to help keep track of the progress of the module build migration to 
Maven2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (GERONIMO-1724) Module migration to Maven 2: client

[Jacek Laskowski (JIRA)]

[ 
http://issues.apache.org/jira/browse/GERONIMO-1724?page=comments#action_12369681
 ] 

Jacek Laskowski commented on GERONIMO-1724:
---

It's almost there. The resources are in src/java, which should be migrated to 
src/resources (before they go to src/main/resources eventually).

> Module migration to Maven 2: client
> ---
>
>  Key: GERONIMO-1724
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1724
>  Project: Geronimo
> Type: Sub-task
> Versions: 1.x
> Reporter: Jacek Laskowski

>
> It's a task to help keep track of the progress of the module build migration 
> to Maven2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Created: (GERONIMO-1725) Module migration to Maven 2: client-builder

[Jacek Laskowski (JIRA)]

Module migration to Maven 2: client-builder
---

 Key: GERONIMO-1725
 URL: http://issues.apache.org/jira/browse/GERONIMO-1725
 Project: Geronimo
Type: Sub-task
Versions: 1.x
Reporter: Jacek Laskowski


It's a task to help keep track of the progress of the module build migration to 
Maven2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Created: (GERONIMO-1726) Module migration to Maven 2: common

[Jacek Laskowski (JIRA)]

Module migration to Maven 2: common
---

 Key: GERONIMO-1726
 URL: http://issues.apache.org/jira/browse/GERONIMO-1726
 Project: Geronimo
Type: Sub-task
  Components: common  
Versions: 1.x
Reporter: Jacek Laskowski


It's almost there. Properties are in incorrect dirs - should go to 
src/properties (and eventually to src/main/properties)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (GERONIMO-1726) Module migration to Maven 2: common

[Jacek Laskowski (JIRA)]

[ 
http://issues.apache.org/jira/browse/GERONIMO-1726?page=comments#action_12369682
 ] 

Jacek Laskowski commented on GERONIMO-1726:
---

It's a task to keep track of the progress of the module build migration to 
Maven2

> Module migration to Maven 2: common
> ---
>
>  Key: GERONIMO-1726
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1726
>  Project: Geronimo
> Type: Sub-task
>   Components: common
> Versions: 1.x
> Reporter: Jacek Laskowski

>
> It's almost there. Properties are in incorrect dirs - should go to 
> src/properties (and eventually to src/main/properties)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: [jira] Resolved: (SM-149) Clustering should be done per endpoint instead of per component

[Sanjiva Weerawarana]

I have a dumb question .. why are these messages coming from
[EMAIL PROTECTED] Shouldn't they come from something @apache.org?

Sanjiva.

On Thu, 2006-03-09 at 10:40 -0800, Guillaume Nodet (JIRA) wrote:
>  [ http://jira.activemq.org/jira//browse/SM-149?page=all ]
>  
> Guillaume Nodet resolved SM-149:
> 
> 
>  Resolution: Fixed
> Fix Version: (was: 3.0)
>  3.0-M1
> 
> > Clustering should be done per endpoint instead of per component
> > ---
> >
> >  Key: SM-149
> >  URL: http://jira.activemq.org/jira//browse/SM-149
> >  Project: ServiceMix
> > Type: Improvement
> 
> >   Components: servicemix-core
> > Reporter: Guillaume Nodet
> > Assignee: Guillaume Nodet
> >  Fix For: 3.0-M1
> 
> >
> >
> > Clustering is currently effective on a per component basis.
> > But this should be done per endpoint, because one service unit may not be 
> > deployed on all components of the cluster.
> 

Re: M2 migration status

[Joe Bohn]

anita kulshreshtha wrote:


I am in favor of running parallel builds until all
the modules can be built even by skipping the tests.
Then we need to go through the dependencies and change
their scopes (compile/test/runtime) and see how m2
handles it. I do not think maven.xmls are being
modified , please correct me if I am wrong. People
modifying project.xml chould make a note in the jira
that the dependency list has been modified. Though if
we do the scope thing right, we should end up with the
same list... Well that is my impression...


I did have to modify just one maven.xml in client-builder but only to 
invoke the dependency plugin.  Most of the other changes are in 
project.xml as you expect (which, btw, is the case for the tomcat 
module).  The changes that I needed to make were to remove, add, and 
relocate dependencies  so these changes would need to be integrated 
prior to changing the scopes for M2 or they would be lost.


Thanks,
Joe


--
Joe Bohn
joe.bohn at earthlink.net

"He is no fool who gives what he cannot keep, to gain what he cannot 
lose."   -- Jim Elliot

Re: [jira] Resolved: (SM-149) Clustering should be done per endpoint instead of per component

[James Strachan]

We've not migrated the JIRA project over yet.

James

On 3/9/06, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote:
>
> I have a dumb question .. why are these messages coming from
> [EMAIL PROTECTED] Shouldn't they come from something @apache.org?
>
> Sanjiva.
>
> On Thu, 2006-03-09 at 10:40 -0800, Guillaume Nodet (JIRA) wrote:
> >  [ http://jira.activemq.org/jira//browse/SM-149?page=all ]
> >
> > Guillaume Nodet resolved SM-149:
> > 
> >
> >  Resolution: Fixed
> > Fix Version: (was: 3.0)
> >  3.0-M1
> >
> > > Clustering should be done per endpoint instead of per component
> > > ---
> > >
> > >  Key: SM-149
> > >  URL: http://jira.activemq.org/jira//browse/SM-149
> > >  Project: ServiceMix
> > > Type: Improvement
> >
> > >   Components: servicemix-core
> > > Reporter: Guillaume Nodet
> > > Assignee: Guillaume Nodet
> > >  Fix For: 3.0-M1
> >
> > >
> > >
> > > Clustering is currently effective on a per component basis.
> > > But this should be done per endpoint, because one service unit may not
> be deployed on all components of the cluster.
> >
>
>


--

James
---
http://radio.weblogs.com/0112098/

[jira] Created: (GERONIMO-1727) Module migration to Maven 2: connector

[Jacek Laskowski (JIRA)]

Module migration to Maven 2: connector
--

 Key: GERONIMO-1727
 URL: http://issues.apache.org/jira/browse/GERONIMO-1727
 Project: Geronimo
Type: Sub-task
  Components: connector  
Versions: 1.x
Reporter: Jacek Laskowski


It's a task to keep track of the progress of the module build migration to 
Maven2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (GERONIMO-1727) Module migration to Maven 2: connector

[Jacek Laskowski (JIRA)]

[ 
http://issues.apache.org/jira/browse/GERONIMO-1727?page=comments#action_12369684
 ] 

Jacek Laskowski commented on GERONIMO-1727:
---

It's almost there with the exception of project.properties that seems to not be 
migrated yet

> Module migration to Maven 2: connector
> --
>
>  Key: GERONIMO-1727
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1727
>  Project: Geronimo
> Type: Sub-task
>   Components: connector
> Versions: 1.x
> Reporter: Jacek Laskowski

>
> It's a task to keep track of the progress of the module build migration to 
> Maven2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Created: (GERONIMO-1728) Module migration to Maven 2: installer-processing

[Jacek Laskowski (JIRA)]

Module migration to Maven 2: installer-processing
-

 Key: GERONIMO-1728
 URL: http://issues.apache.org/jira/browse/GERONIMO-1728
 Project: Geronimo
Type: Sub-task
  Components: installer  
Versions: 1.x
Reporter: Jacek Laskowski


It's a task to keep track of the progress of the module build migration to 
Maven2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Created: (GERONIMO-1729) Module migration to Maven 2: installer-support

[Jacek Laskowski (JIRA)]

Module migration to Maven 2: installer-support
--

 Key: GERONIMO-1729
 URL: http://issues.apache.org/jira/browse/GERONIMO-1729
 Project: Geronimo
Type: Sub-task
  Components: installer  
Versions: 1.x
Reporter: Jacek Laskowski


It's a task to keep track of the progress of the module build migration to 
Maven2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Created: (GERONIMO-1730) Module migration to Maven 2: interop

[Jacek Laskowski (JIRA)]

Module migration to Maven 2: interop


 Key: GERONIMO-1730
 URL: http://issues.apache.org/jira/browse/GERONIMO-1730
 Project: Geronimo
Type: Sub-task
Versions: 1.x
Reporter: Jacek Laskowski


It's a task to keep track of the progress of the module build migration to 
Maven2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (GERONIMO-1613) Eliminate unncessary dependencies to reduce assemnbly footprint size

[Joe Bohn (JIRA)]

[ 
http://issues.apache.org/jira/browse/GERONIMO-1613?page=comments#action_12369689
 ] 

Joe Bohn commented on GERONIMO-1613:


Part of the work was already integrated prior to the start of the M2 conversion 
... so that portion should be ok.  The other portion was completed in the patch 
before most of the M2 conversion work began.  I've been trying to identify 
areas where there may be "dueling changes" so that we can work together to 
ensure nothing is lost on either effort. 

On the plus side, I think the overlap is fairly small.  Most of the changes for 
the M2 conversion have been in the modules and plugins while most of these 
changes are in the configs.  I've also been told that changes in the 
project.xml for dependencies have not yet been addressed in the M2 conversion 
where the scope needs to be set.  So, hopefully we'll be able to get this work 
integrated before the dependency scopes are set and before the 
configs/assemblies are converted to M2.  

> Eliminate unncessary dependencies to reduce assemnbly footprint size
> 
>
>  Key: GERONIMO-1613
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1613
>  Project: Geronimo
> Type: Improvement
>   Components: general
> Versions: 1.2
>  Environment: all
> Reporter: Joe Bohn
> Assignee: Jeff Genender
>  Fix For: 1.2
>  Attachments: 1613_RemoveDeps3.patch, 1613_RemoveDeps4.patch, 
> RemoveDeps.patch, RemoveDeps2.1.patch, RemoveDeps2.2.patch, 
> RemoveDeps2.3.patch, RemoveDeps2.patch
>
> Clean up assembly project.xml and eliminate some unnecessary dependencies in 
> various modules and configs.  This will reduce the footprint size (with 
> special attention to the minimal-tomcat-assembly.
> The patch contains the following:
> - clean up minimal-tomcat-server\project.xml to remove commented out sections
> - clean up web-jms-tomcat-server\project.xml to remove commented out sections
> - remove dependencies from config\j2ee_server on xstream, jaxr-api, and 
> geronimo-derby
> - remove dependencies from config\j2ee_deployer on geronimo-client-builder
> - remove dependencies from module\tomcat on activecluster, wadi-core, and 
> wadi-tomcat55
> There are still more dependencies that should be removed but this is a start.
> These changes reduce the disk footprint of minimal-tomcat-server from 27 meg 
> to about 21 meg.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Created: (GERONIMO-1731) Module migration to Maven 2: jetty

[Jacek Laskowski (JIRA)]

Module migration to Maven 2: jetty
--

 Key: GERONIMO-1731
 URL: http://issues.apache.org/jira/browse/GERONIMO-1731
 Project: Geronimo
Type: Sub-task
Versions: 1.x
Reporter: Jacek Laskowski


It's a task to keep track of the progress of the module build migration to 
Maven2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Created: (GERONIMO-1732) Module migration to Maven 2: jetty-builder

[Jacek Laskowski (JIRA)]

Module migration to Maven 2: jetty-builder
--

 Key: GERONIMO-1732
 URL: http://issues.apache.org/jira/browse/GERONIMO-1732
 Project: Geronimo
Type: Sub-task
Versions: 1.x
Reporter: Jacek Laskowski


It's a task to keep track of the progress of the module build migration to 
Maven2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: M2 migration status

[Prasad Kashyap]

I delete my entire geronimo source directory and do a fresh svn
checkout everyday. Yesterday, I even deleted my entire m2 local.repo

These are the test errors I see when I built from inside the module or
from top down.

[INFO] Setting reports dir:
C:\Apache\geronimo\modules\security\target/surefire-reports
---
 T E S T S
---
[surefire] Running org.apache.geronimo.security.ContextManagerTest
[surefire] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.15
sec  FAILURE !!
[surefire] Running org.apache.geronimo.security.jaas.ConfigurationEntryTest
[surefire] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 1.111
sec  FAILURE !!
[surefire] Running
org.apache.geronimo.security.jaas.LoginKerberosNonGeronimoTest
[surefire] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.881 sec
[surefire] Running org.apache.geronimo.security.jaas.LoginKerberosTest
[surefire] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.891 sec
[surefire] Running org.apache.geronimo.security.jaas.LoginPropertiesFileTest
[surefire] Tests run: 5, Failures: 0, Errors: 1, Time elapsed: 2.844
sec  FAILURE !!
[surefire] Running org.apache.geronimo.security.jaas.LoginSQLTest
[surefire] Tests run: 3, Failures: 0, Errors: 3, Time elapsed: 0.931
sec  FAILURE !!
[surefire] Running org.apache.geronimo.security.jaas.MultipleLoginDomainTest
[surefire] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.06 sec
[surefire] Running org.apache.geronimo.security.jaas.NoLoginModuleReuseTest
[surefire] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.05 sec
[surefire] Running org.apache.geronimo.security.jaas.TimeoutTest
[surefire] Tests run: 2, Failures: 0, Errors: 1, Time elapsed: 1.692
sec  FAILURE !!
[surefire] Running
org.apache.geronimo.security.jacc.GeronimoPolicyConfigurationFactoryTest
[surefire] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.03 sec
[surefire] Running
org.apache.geronimo.security.network.protocol.SubjectCarryingProtocolTest
[surefire] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 1.112
sec  FAILURE !!
[surefire] Running org.apache.geronimo.security.remoting.jmx.RemoteLoginTest
[surefire] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 1.142
sec  FAILURE !!
[INFO] 

[ERROR] BUILD ERROR
[INFO] 



On 3/9/06, Jacek Laskowski <[EMAIL PROTECTED]> wrote:
> 2006/3/9, Prasad Kashyap <[EMAIL PROTECTED]>:
> > The 2 modules having issues  are security and j2ee-schema.
>
> What issues are you seeing in the security module? Just double-checked
> it and it worked for me (be it executed in its own directory or in the
> top-level directory with maven-surefire-plugin directory renamed in
> the m2 local repo).

>
> > For now, we need to skip tests for security. Is it still correct that
> > a later surefire plugin or maven releases will fix it for us ?
>
> Are you working with the latest sources? It seems you're not.



>
>
> > Prasad.
>
> Jacek
>
> --
> Jacek Laskowski
> http://www.laskowski.org.pl
>

[jira] Created: (GERONIMO-1733) Module migration to Maven 2: mail

[Jacek Laskowski (JIRA)]

Module migration to Maven 2: mail
-

 Key: GERONIMO-1733
 URL: http://issues.apache.org/jira/browse/GERONIMO-1733
 Project: Geronimo
Type: Sub-task
  Components: mail  
Versions: 1.x
Reporter: Jacek Laskowski


It's a task to keep track of the progress of the module build migration to 
Maven2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (GERONIMO-1733) Module migration to Maven 2: mail

[Jacek Laskowski (JIRA)]

[ 
http://issues.apache.org/jira/browse/GERONIMO-1733?page=comments#action_12369691
 ] 

Jacek Laskowski commented on GERONIMO-1733:
---

It's almost there, but some tasks are excluded in m2 yet they weren't in M1

> Module migration to Maven 2: mail
> -
>
>  Key: GERONIMO-1733
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1733
>  Project: Geronimo
> Type: Sub-task
>   Components: mail
> Versions: 1.x
> Reporter: Jacek Laskowski

>
> It's a task to keep track of the progress of the module build migration to 
> Maven2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (GBUILD-16) Improve GBuild agent JMS reconnect logic

[David Blevins (JIRA)]

 [ http://issues.apache.org/jira/browse/GBUILD-16?page=all ]

David Blevins updated GBUILD-16:


Summary: Improve GBuild agent JMS reconnect logic  (was: GBuild agent JMS 
reconnect logic is incorrect)

The activemq feature could potentially be our aggressive reconnect strategy and 
the current code (sans the two hard-coded values) could maybe be used for the 
more passive mode.  Maybe change the delay setting to minutes.

I can verify that the reconnect logic and synchronization around it all work.

> Improve GBuild agent JMS reconnect logic
> 
>
>  Key: GBUILD-16
>  URL: http://issues.apache.org/jira/browse/GBUILD-16
>  Project: GBuild
> Type: Bug
>   Components: agent
> Versions: 1.0.0
> Reporter: Kevan Miller
> Assignee: Kevan Miller
> Priority: Minor

>
> The gbuild agent reconnect logic has several problems.
> User configuration settings for reconnect processing are ignored. Max retries 
> and delay time are all hard-coded. 
> If the initial connection fails, it seems that the client will never connect.
> Also, we should be able to configure agents to attempt to reconnect forever. 
> There should be some retry backoff scheme or bimodal reconnect interval... 
> I seem to recall that ActiveMQ has similar features in their client api. It 
> might be simpler to remove what GBuild currently does and use the built-in 
> ActiveMQ support...
>   

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (GBUILD-15) GBuild reads and processes all files in the tasks directory, it should only read and process ".properties" files

[David Blevins (JIRA)]

[ 
http://issues.apache.org/jira/browse/GBUILD-15?page=comments#action_12369696 ] 

David Blevins commented on GBUILD-15:
-

Something that just popped into my head on this one is that we should make the 
".properties" extension a configurable option, moreover use a regular 
expression so someone could match everything or simply a different file pattern 
if they wished.

The HeaderIncludeExtension, BuildAgentExtension, and BuildResultsExtension do 
similar things with the strings that they look for to do their work.



> GBuild reads and processes all files in the tasks directory, it should only 
> read and process ".properties" files
> 
>
>  Key: GBUILD-15
>  URL: http://issues.apache.org/jira/browse/GBUILD-15
>  Project: GBuild
> Type: Improvement
> Versions: 1.0.0
> Reporter: Kevan Miller
> Assignee: Kevan Miller
> Priority: Minor

>
> PropertiesBuildTaskProducer should only read ".properties" files when 
> creating GBuild tasks. However, it currently reads any file in the tasks 
> directory and attempts to generate build tasks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Created: (GERONIMO-1734) Module migration to Maven 2: naming-builder

[Jacek Laskowski (JIRA)]

Module migration to Maven 2: naming-builder
---

 Key: GERONIMO-1734
 URL: http://issues.apache.org/jira/browse/GERONIMO-1734
 Project: Geronimo
Type: Sub-task
  Components: naming  
Versions: 1.x
Reporter: Jacek Laskowski


It's a task to keep track of the progress of the module build migration to 
Maven2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (GERONIMO-1734) Module migration to Maven 2: naming-builder

[Jacek Laskowski (JIRA)]

[ 
http://issues.apache.org/jira/browse/GERONIMO-1734?page=comments#action_12369697
 ] 

Jacek Laskowski commented on GERONIMO-1734:
---

It's almost there, but there're some xmlbeans processing that should be checked 
out before announcing the successful migration of the module.

> Module migration to Maven 2: naming-builder
> ---
>
>  Key: GERONIMO-1734
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1734
>  Project: Geronimo
> Type: Sub-task
>   Components: naming
> Versions: 1.x
> Reporter: Jacek Laskowski

>
> It's a task to keep track of the progress of the module build migration to 
> Maven2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (GERONIMO-1717) directory module migration to Maven2

[Prasad Kashyap (JIRA)]

[ 
http://issues.apache.org/jira/browse/GERONIMO-1717?page=comments#action_12369699
 ] 

Prasad Kashyap commented on GERONIMO-1717:
--

Well, this module has some project.properties entries. Don't know yet what to 
do with those. Will need to investigate.

maven.junit.jvmargs=-Djava.endorsed.dirs=${maven.build.dir}/endorsed -ea 
maven.junit.fork=true

maven.eclipse.classpath.include=${basedir}/target/xmlbeans,${basedir}/target/xmlbeans-classes

maven.idea.generated.source=xmlbeans

> directory module migration to Maven2
> 
>
>  Key: GERONIMO-1717
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1717
>  Project: Geronimo
> Type: Sub-task
> Reporter: Prasad Kashyap
>  Attachments: directory.patch
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: M2 migration status

[Henri Yandell]

On 3/9/06, Joe Bohn <[EMAIL PROTECTED]> wrote:
>
> Prasad Kashyap wrote:
>
> > Here's my next concern. For these modules that have migrated to m2, we
> > should include them in the daily G builds as soon as possible. If we
> > don't pull out the m1 build artifacts, project.xml and maven.xml from
> > the migrated modules, then there's a chance that those may get changed
> > behind our backs while we go forward converting more. There might be a
> > regression of issues.
>
> I have the same concern and voiced it (from the other direction) in my
> post on little-G.

Ditto, so I now start my day by running a build-fresh-geronimo script. :)

Hen

[jira] Commented: (GERONIMO-1735) Module migration to Maven 2: transaction

[Jacek Laskowski (JIRA)]

[ 
http://issues.apache.org/jira/browse/GERONIMO-1735?page=comments#action_12369710
 ] 

Jacek Laskowski commented on GERONIMO-1735:
---

It's almost there, but there's at least one uprocessed file in src/etc 
directory.

> Module migration to Maven 2: transaction
> 
>
>  Key: GERONIMO-1735
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1735
>  Project: Geronimo
> Type: Sub-task
>   Components: transaction manager
> Versions: 1.x
> Reporter: Jacek Laskowski

>
> It's a task to keep track of the progress of the module build migration to 
> Maven2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Created: (GERONIMO-1735) Module migration to Maven 2: transaction

[Jacek Laskowski (JIRA)]

Module migration to Maven 2: transaction


 Key: GERONIMO-1735
 URL: http://issues.apache.org/jira/browse/GERONIMO-1735
 Project: Geronimo
Type: Sub-task
  Components: transaction manager  
Versions: 1.x
Reporter: Jacek Laskowski


It's a task to keep track of the progress of the module build migration to 
Maven2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: M2 migration status

[anita kulshreshtha]

Does the report say a test kernel is already
running?

Thanks
Anita

--- Prasad Kashyap <[EMAIL PROTECTED]>
wrote:

> I delete my entire geronimo source directory and do
> a fresh svn
> checkout everyday. Yesterday, I even deleted my
> entire m2 local.repo
> 
> These are the test errors I see when I built from
> inside the module or
> from top down.
> 
> [INFO] Setting reports dir:
>
C:\Apache\geronimo\modules\security\target/surefire-reports
>
---
>  T E S T S
>
---
> [surefire] Running
> org.apache.geronimo.security.ContextManagerTest
> [surefire] Tests run: 1, Failures: 0, Errors: 1,
> Time elapsed: 0.15
> sec  FAILURE !!
> [surefire] Running
>
org.apache.geronimo.security.jaas.ConfigurationEntryTest
> [surefire] Tests run: 1, Failures: 0, Errors: 1,
> Time elapsed: 1.111
> sec  FAILURE !!
> [surefire] Running
>
org.apache.geronimo.security.jaas.LoginKerberosNonGeronimoTest
> [surefire] Tests run: 1, Failures: 0, Errors: 0,
> Time elapsed: 0.881 sec
> [surefire] Running
> org.apache.geronimo.security.jaas.LoginKerberosTest
> [surefire] Tests run: 1, Failures: 0, Errors: 0,
> Time elapsed: 0.891 sec
> [surefire] Running
>
org.apache.geronimo.security.jaas.LoginPropertiesFileTest
> [surefire] Tests run: 5, Failures: 0, Errors: 1,
> Time elapsed: 2.844
> sec  FAILURE !!
> [surefire] Running
> org.apache.geronimo.security.jaas.LoginSQLTest
> [surefire] Tests run: 3, Failures: 0, Errors: 3,
> Time elapsed: 0.931
> sec  FAILURE !!
> [surefire] Running
>
org.apache.geronimo.security.jaas.MultipleLoginDomainTest
> [surefire] Tests run: 2, Failures: 0, Errors: 0,
> Time elapsed: 0.06 sec
> [surefire] Running
>
org.apache.geronimo.security.jaas.NoLoginModuleReuseTest
> [surefire] Tests run: 1, Failures: 0, Errors: 0,
> Time elapsed: 0.05 sec
> [surefire] Running
> org.apache.geronimo.security.jaas.TimeoutTest
> [surefire] Tests run: 2, Failures: 0, Errors: 1,
> Time elapsed: 1.692
> sec  FAILURE !!
> [surefire] Running
>
org.apache.geronimo.security.jacc.GeronimoPolicyConfigurationFactoryTest
> [surefire] Tests run: 2, Failures: 0, Errors: 0,
> Time elapsed: 0.03 sec
> [surefire] Running
>
org.apache.geronimo.security.network.protocol.SubjectCarryingProtocolTest
> [surefire] Tests run: 1, Failures: 0, Errors: 1,
> Time elapsed: 1.112
> sec  FAILURE !!
> [surefire] Running
>
org.apache.geronimo.security.remoting.jmx.RemoteLoginTest
> [surefire] Tests run: 1, Failures: 0, Errors: 1,
> Time elapsed: 1.142
> sec  FAILURE !!
> [INFO]
>

> [ERROR] BUILD ERROR
> [INFO]
>

> 
> 
> On 3/9/06, Jacek Laskowski <[EMAIL PROTECTED]>
> wrote:
> > 2006/3/9, Prasad Kashyap
> <[EMAIL PROTECTED]>:
> > > The 2 modules having issues  are security and
> j2ee-schema.
> >
> > What issues are you seeing in the security module?
> Just double-checked
> > it and it worked for me (be it executed in its own
> directory or in the
> > top-level directory with maven-surefire-plugin
> directory renamed in
> > the m2 local repo).
> 
> >
> > > For now, we need to skip tests for security. Is
> it still correct that
> > > a later surefire plugin or maven releases will
> fix it for us ?
> >
> > Are you working with the latest sources? It seems
> you're not.
> 
> 
> 
> >
> >
> > > Prasad.
> >
> > Jacek
> >
> > --
> > Jacek Laskowski
> > http://www.laskowski.org.pl
> >
> 


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

[jira] Commented: (GBUILD-16) Improve GBuild agent JMS reconnect logic

[Kevan Miller (JIRA)]

[ 
http://issues.apache.org/jira/browse/GBUILD-16?page=comments#action_12369714 ] 

Kevan Miller commented on GBUILD-16:


Here's some info on what ActiveMQ provides -- 
http://activemq.codehaus.org/Failover+Transport+Reference

It seems to provide for the configuration of a retry backoff strategy. Assuming 
it all works, it should provide the desired function -- fast recovery for 
short-term problems and long-term recovery for long outages. I don't view the 
backoff capabilities as super critical, anyway. We could set a fixed retry rate 
of 30 seconds with few negative consequences... 

Apologies if I was overly harsh in my summary of the problems...

> Improve GBuild agent JMS reconnect logic
> 
>
>  Key: GBUILD-16
>  URL: http://issues.apache.org/jira/browse/GBUILD-16
>  Project: GBuild
> Type: Bug
>   Components: agent
> Versions: 1.0.0
> Reporter: Kevan Miller
> Assignee: Kevan Miller
> Priority: Minor

>
> The gbuild agent reconnect logic has several problems.
> User configuration settings for reconnect processing are ignored. Max retries 
> and delay time are all hard-coded. 
> If the initial connection fails, it seems that the client will never connect.
> Also, we should be able to configure agents to attempt to reconnect forever. 
> There should be some retry backoff scheme or bimodal reconnect interval... 
> I seem to recall that ActiveMQ has similar features in their client api. It 
> might be simpler to remove what GBuild currently does and use the built-in 
> ActiveMQ support...
>   

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Created: (GERONIMO-1736) Module migration to Maven 2: web-builder

[Jacek Laskowski (JIRA)]

Module migration to Maven 2: web-builder


 Key: GERONIMO-1736
 URL: http://issues.apache.org/jira/browse/GERONIMO-1736
 Project: Geronimo
Type: Sub-task
  Components: web  
Versions: 1.x
Reporter: Jacek Laskowski


It's a task to keep track of the progress of the module build migration to 
Maven2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

valid XML checking

[Lin Sun]

Hi
there,

 

I’ve
spent quite some time trying to get the MDB sample (http://opensource2.atlassian.com/confluence/oss/display/GERONIMO/JBoss+to+Geronimo+-+EJB-MDB+Migration)
deployed using the eclipse plugin.   I was able to get it running
eventually but I had to spend extra time in modifying the deployment plan to bypass
the valid XML checking.   The extra editing is are not needed if I
use the command line deployer or admin console.

 

The
problem is that the plugin checks the deployment plan very strictly.  I have to use fully qualified elements, otherwise the
plans are not treated as valid xmls, and the model editor will not be able to parse
the resource and throws exception in the eclipse log.

 

For example:  the following is not treated as valid Geronimo
deployment plan in eclipse environment.   But the command line deployer or admin console likes it:

 

  

    ejb/CustomerHome

    

  geronimo.server:EJBModule=MDBDemo,J2EEApplication=null,J2EEServer=geronimo,j2eeType=EntityBean,name=CustomerEJB

   

  

 

I had to change it to the following just for Eclipse
environment.  (xmlns:nam=http://geronimo.apache.org/xml/ns/naming-1.0
is specified earlier in the plan)

 

  

    ejb/CustomerHome

    

  geronimo.server:EJBModule=MDBDemo,J2EEApplication=null,J2EEServer=geronimo,j2eeType=EntityBean,name=CustomerEJB

    

  

 

Ideally,
we don’t want users to perform such extra efforts while porting their Geronimo
specific plans in eclipse.   I am not sure what can be done in the plugin
code to perform a loose XML checking… it seems to use the
WTP/pre-requisites’ code to perform the XML checking.   Thoughts?

 

Thanks, 

 

Lin

 

[jira] Commented: (GERONIMO-1736) Module migration to Maven 2: web-builder

[Jacek Laskowski (JIRA)]

[ 
http://issues.apache.org/jira/browse/GERONIMO-1736?page=comments#action_12369715
 ] 

Jacek Laskowski commented on GERONIMO-1736:
---

It's almost there, but there're some xmlbeans processing and additional 
resources specified which all need to be checked out carefully before we 
announce its final migration step.

> Module migration to Maven 2: web-builder
> 
>
>  Key: GERONIMO-1736
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1736
>  Project: Geronimo
> Type: Sub-task
>   Components: web
> Versions: 1.x
> Reporter: Jacek Laskowski

>
> It's a task to keep track of the progress of the module build migration to 
> Maven2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: M2 migration status

[anita kulshreshtha]

comments inline...

--- Joe Bohn <[EMAIL PROTECTED]> wrote:

> 
> 
> anita kulshreshtha wrote:
> 
> > I am in favor of running parallel builds until
> all
> > the modules can be built even by skipping the
> tests.
> > Then we need to go through the dependencies and
> change
> > their scopes (compile/test/runtime) and see how m2
> > handles it. I do not think maven.xmls are being
> > modified , please correct me if I am wrong. People
> > modifying project.xml chould make a note in the
> jira
> > that the dependency list has been modified. Though
> if
> > we do the scope thing right, we should end up with
> the
> > same list... Well that is my impression...
> 
> I did have to modify just one maven.xml in
> client-builder but only to 
> invoke the dependency plugin.
   We will be revisiting all the *-builders
soon.  
 Most of the other
> changes are in 
> project.xml as you expect (which, btw, is the case
> for the tomcat 
> module).  The changes that I needed to make were to
> remove, add, and 
> relocate dependencies  so these changes would
> need to be integrated 
> prior to changing the scopes for M2 or they would be
> lost.
 As soon as the the changes are committed, I will
update tomcat module. I am making a note about this in
the jira.

Thnaks
Anita
> 
> Thanks,
> Joe
> 
> 
> -- 
> Joe Bohn
> joe.bohn at earthlink.net
> 
> "He is no fool who gives what he cannot keep, to
> gain what he cannot 
> lose."   -- Jim Elliot
> 


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

[jira] Commented: (GERONIMO-1645) tomcat module migration to Maven2

[Anita Kulshreshtha (JIRA)]

[ 
http://issues.apache.org/jira/browse/GERONIMO-1645?page=comments#action_12369720
 ] 

Anita Kulshreshtha commented on GERONIMO-1645:
--

Need to update the dependency list because of Little-G. Please keep this issue 
open.

> tomcat module migration to Maven2
> -
>
>  Key: GERONIMO-1645
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1645
>  Project: Geronimo
> Type: Sub-task
>   Components: Tomcat
> Versions: 1.x
> Reporter: Jacek Laskowski
> Assignee: Anita Kulshreshtha
>  Attachments: maven-metadata-local.xml, pom.patch, pom.patch, pom.patch, 
> pom.xml, pom.xml, pom.xml, pom.xml
>
> It's a task to help keep track of the progress of the tomcat module build 
> migration to Maven2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (GERONIMO-1717) directory module migration to Maven2

[Jacek Laskowski (JIRA)]

[ 
http://issues.apache.org/jira/browse/GERONIMO-1717?page=comments#action_12369721
 ] 

Jacek Laskowski commented on GERONIMO-1717:
---

The first two properties are for maven-surefire-plugin and don't think they're 
important. Why would the endorsed dir be necessary for the module is beyond my 
understanding. If the tests work we can get rid of it.

The other two are for IDEs and I think we shouldn't worry about it that much, 
either.

> directory module migration to Maven2
> 
>
>  Key: GERONIMO-1717
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1717
>  Project: Geronimo
> Type: Sub-task
> Reporter: Prasad Kashyap
>  Attachments: directory.patch
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (GERONIMO-1717) directory module migration to Maven2

[Prasad Kashyap (JIRA)]

[ 
http://issues.apache.org/jira/browse/GERONIMO-1717?page=comments#action_12369724
 ] 

Prasad Kashyap commented on GERONIMO-1717:
--

The tests work. In that case, we can consider this module migrated too.

Cheers
Prasad

> directory module migration to Maven2
> 
>
>  Key: GERONIMO-1717
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1717
>  Project: Geronimo
> Type: Sub-task
> Reporter: Prasad Kashyap
>  Attachments: directory.patch
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (GERONIMO-1677) Plugin migration to Maven 2: geronimo-dependency-plugin

[Jacek Laskowski (JIRA)]

 [ http://issues.apache.org/jira/browse/GERONIMO-1677?page=all ]

Jacek Laskowski updated GERONIMO-1677:
--

  Component: buildsystem
Summary: Plugin migration to Maven 2: geronimo-dependency-plugin  (was: 
geronimo-dependency-plugin deletion)
Description: 
Version: 1.x
Environment: 

> Plugin migration to Maven 2: geronimo-dependency-plugin
> ---
>
>  Key: GERONIMO-1677
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1677
>  Project: Geronimo
> Type: Sub-task
>   Components: buildsystem
> Versions: 1.x
> Reporter: Prasad Kashyap

>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Created: (GERONIMO-1737) Plugin migration to Maven 2: geronimo-assembly-plugin

[Jacek Laskowski (JIRA)]

Plugin migration to Maven 2: geronimo-assembly-plugin
-

 Key: GERONIMO-1737
 URL: http://issues.apache.org/jira/browse/GERONIMO-1737
 Project: Geronimo
Type: Sub-task
  Components: buildsystem  
Versions: 1.x
Reporter: Jacek Laskowski


It's a task to keep track of the progress of the plugin build migration to 
Maven2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Created: (GERONIMO-1738) Plugin migration to Maven 2: geronimo-deployment-plugin

[Jacek Laskowski (JIRA)]

Plugin migration to Maven 2: geronimo-deployment-plugin
---

 Key: GERONIMO-1738
 URL: http://issues.apache.org/jira/browse/GERONIMO-1738
 Project: Geronimo
Type: Sub-task
  Components: buildsystem  
Versions: 1.x
Reporter: Jacek Laskowski


It's a task to keep track of the progress of the plugin build migration to 
Maven2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: Sun copyrights and our rights to include certain files in the repo

[Bill Dudney]

Hi all,

This can't be the first time this has ever come up can it? Many of  
the xsd and dtd's that are  in G for J2EE 1.4  were copied from  
Tomcat 5.x so they had to have gotten this straightened out, right? ;-)


I'd be happy to get the conversation going with legal, but its  
probably better that it come from a G committer.


Thoughts?

Bill Dudney
MyFaces - myfaces.apache.org

On Mar 9, 2006, at 9:41 AM, Jeff Genender wrote:


Here is what it says in the DTD:

"This document and the product to which it pertains are distributed
under licenses restricting their use, copying, distribution, and
decompilation.  This document may be reproduced and distributed but  
may

not be changed without prior written authorization of Sun and its
licensors, if any."

So, from this blurb, it would appear we can include the DTDs and XSDs,
but we *cannot* change it.  Would this be a correct assessment?

Jeff

Geir Magnusson Jr wrote:

Exactly the right question - the copyright isn't the issue, but the
license is.

Where did these schemas come from, and what are the listed terms?

geir

Bill Stoddard wrote:

Jacek Laskowski wrote:

2006/3/9, Bill Stoddard <[EMAIL PROTECTED]>:


Don't change the copyright statements. The only time it is
acceptable to change copyright statements is when
the copyright holder has assigned copyright ownership to the ASF.


Has it been assigned? If not, my understanding is that we're not
allowed to store them in the repo, either.



That's the wrong question. ASF repositories contain lots of code for
which the ASF is not the copyright owner. Whether we are allowed to
store code in our repositories depends on the license terms and
conditions issued by the copyright holder.  What are the T&C's for
this code? Do we know?

Bill

[jira] Created: (GERONIMO-1739) Plugin migration to Maven 2: geronimo-izpack-plugin

[Jacek Laskowski (JIRA)]

Plugin migration to Maven 2: geronimo-izpack-plugin
---

 Key: GERONIMO-1739
 URL: http://issues.apache.org/jira/browse/GERONIMO-1739
 Project: Geronimo
Type: Sub-task
  Components: buildsystem  
Versions: 1.x
Reporter: Jacek Laskowski


It's a task to keep track of the progress of the plugin build migration to 
Maven2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Created: (GERONIMO-1740) Plugin migration to Maven 2: geronimo-packaging-plugin

[Jacek Laskowski (JIRA)]

Plugin migration to Maven 2: geronimo-packaging-plugin
--

 Key: GERONIMO-1740
 URL: http://issues.apache.org/jira/browse/GERONIMO-1740
 Project: Geronimo
Type: Sub-task
  Components: buildsystem  
Versions: 1.x
Reporter: Jacek Laskowski


It's a task to keep track of the progress of the plugin build migration to 
Maven2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Closed: (GERONIMO-1717) directory module migration to Maven2

[Jacek Laskowski (JIRA)]

 [ http://issues.apache.org/jira/browse/GERONIMO-1717?page=all ]
 
Jacek Laskowski closed GERONIMO-1717:
-

Fix Version: 1.x
 Resolution: Fixed

Verified. Thanks Prasad!

> directory module migration to Maven2
> 
>
>  Key: GERONIMO-1717
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1717
>  Project: Geronimo
> Type: Sub-task
> Reporter: Prasad Kashyap
>  Fix For: 1.x
>  Attachments: directory.patch
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Assigned: (GERONIMO-851) Move Geronimo Build to M2 (Maven 2)

[Jacek Laskowski (JIRA)]

 [ http://issues.apache.org/jira/browse/GERONIMO-851?page=all ]

Jacek Laskowski reassigned GERONIMO-851:


Assign To: Jacek Laskowski  (was: John Sisson)

> Move Geronimo Build to M2 (Maven 2)
> ---
>
>  Key: GERONIMO-851
>  URL: http://issues.apache.org/jira/browse/GERONIMO-851
>  Project: Geronimo
> Type: Task
>   Components: buildsystem
> Reporter: John Sisson
> Assignee: Jacek Laskowski
>  Fix For: 1.x
>  Attachments: parentpom.patch
>
> Created this issue to keep track of the status of work to move the Geronimo 
> build to Maven 2.  Does anyone know the status of this effort? I believe some 
> work was done in OpenEJB? When is the move to M2 planned for? 1.0 or 1.1
> FYI.. In June I attempted to use Maven 1.1 beta 1 to build geronimo and got 
> some parse exceptions in maven.  As a result, some small changes were made to 
> some project.xml files by David Jencks, which fixed the parse problem, but we 
> then ran into another problem where we were getting a 
> java.lang.NoSuchMethodError in maven.  This should now be fixed using an 
> updated artifact plugin, see http://jira.codehaus.org/browse/MAVEN-1625 (but 
> I have not verified this).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: valid XML checking

[David Jencks]

The builders all run plans through SchemaConversionUtils to install the correct namespaces.  Is there some way to get eclipse to do that?I don't know if it would be a good idea to then save the converted version.thanksdavid jencksOn Mar 9, 2006, at 10:53 AM, Lin Sun wrote:Hi there, I’ve spent quite some time trying to get the MDB sample (http://opensource2.atlassian.com/confluence/oss/display/GERONIMO/JBoss+to+Geronimo+-+EJB-MDB+Migration) deployed using the eclipse plugin.   I was able to get it running eventually but I had to spend extra time in modifying the deployment plan to bypass the valid XML checking.   The extra editing is are not needed if I use the command line deployer or admin console. The problem is that the plugin checks the deployment plan very strictly.  I have to use fully qualified elements, otherwise the plans are not treated as valid xmls, and the model editor will not be able to parse the resource and throws exception in the eclipse log. For example:  the following is not treated as valid Geronimo deployment plan in eclipse environment.   But thecommand line deployer or admin console likes it:       ejb/CustomerHome      geronimo.server:EJBModule=MDBDemo,J2EEApplication=null,J2EEServer=geronimo,j2eeType=EntityBean,name=CustomerEJB      I had to change it to the following just for Eclipse environment.  (xmlns:nam=http://geronimo.apache.org/xml/ns/naming-1.0 is specified earlier in the plan)       ejb/CustomerHome      geronimo.server:EJBModule=MDBDemo,J2EEApplication=null,J2EEServer=geronimo,j2eeType=EntityBean,name=CustomerEJB       Ideally, we don’t want users to perform such extra efforts while porting their Geronimo specific plans in eclipse.   I am not sure what can be done in the plugin code to perform a loose XML checking… it seems to use the WTP/pre-requisites’ code to perform the XML checking.   Thoughts? Thanks, Lin