Okay, I take it back... Maven plugin dependency handling is
completely broke, as it pollutes the classpath of other plugins...
With this change the car plugin starts to barf... so for the time
being I'm backing this out.
--jason
On Aug 21, 2006, at 10:54 PM, Jason Dillon wrote:
I recentl
[ http://issues.apache.org/jira/browse/GERONIMO-2326?page=all ]
David Jencks updated GERONIMO-2326:
---
Attachment: GERONIMO-2326.djencks.patch
I worked on the dependencies and may have solved the dependency problems. I'm
having problems apparently with
On Aug 21, 2006, at 11:09 PM, Jason Dillon wrote:
Close our eyes?
Why should it matter? They can all live in the same tree... just
some with 1.5 and some with 1.4 compiles.
I think you read the email too fast :)
-David
--jason
On Aug 21, 2006, at 10:44 PM, David Blevins wrote:
On
Close our eyes?
Why should it matter? They can all live in the same tree... just
some with 1.5 and some with 1.4 compiles.
--jason
On Aug 21, 2006, at 10:44 PM, David Blevins wrote:
On Aug 21, 2006, at 7:13 PM, Kevan Miller wrote:
I think the source of complexity is the granularity of
I recently discovered that if a parent pom adds an antrun plugin
execution to build, that children can not add dependencies, which
causes some problems further down in the build. I was going to use
antrun to install LICENSE.txt and NOTICE.txt into target/classes/META-
INF as a work around t
On Aug 21, 2006, at 7:13 PM, Kevan Miller wrote:
I think the source of complexity is the granularity of versioning
we're trying to apply to specs... I wonder if the simplest course
of action is to stop releasing individually versioned specs, and
instead always release all specs. When an up
On Aug 21, 2006, at 9:21 PM, David Blevins wrote:
On Aug 21, 2006, at 7:13 PM, Kevan Miller wrote:
As long as we have inter-dependencies between specs (e.g. javamail
depends on activation; jaxrpc on saaj, qname, and servlet; and
especially geronimo-spec-j2ee depends on everything), I'm no
[ http://issues.apache.org/jira/browse/GERONIMO-2274?page=all ]
Vamsavardhana Reddy updated GERONIMO-2274:
--
Attachment: GERONIMO-2274.patch
GERONIMO-2274.patch: Fixes the problem in SecurityBuilder. SecurityBuilder is
passing realmName instead
On Aug 21, 2006, at 7:13 PM, Kevan Miller wrote:
As long as we have inter-dependencies between specs (e.g. javamail
depends on activation; jaxrpc on saaj, qname, and servlet; and
especially geronimo-spec-j2ee depends on everything), I'm not
convinced that this really makes things any bette
I'll try to look at this in the next couple days. I have to spend some time on a plane and will have somewhat limited internet access so if someone such as alan wants to take a look that would be fine.I think we need Matts approval to put it in 1.1.1thanksdavid jencksOn Aug 21, 2006, at 6:16 PM, V
I have picked this up. I think that this could wait for 1.1.2 since
1.1.1 is already in the TCK oven. What do others think?
Regards,
Alan
Vamsavardhana Reddy wrote:
Hello,
GERONIMO-2294
In security realm with multiple login
modules, anything after the first is ignored
is categorized
[ http://issues.apache.org/jira/browse/GERONIMO-2294?page=all ]
Alan Cabrera reassigned GERONIMO-2294:
--
Assignee: Alan Cabrera (was: Vamsavardhana Reddy)
> In security realm with multiple login modules, anything after the first is
> ignored
>
[ http://issues.apache.org/jira/browse/GERONIMO-2274?page=all ]
Vamsavardhana Reddy reassigned GERONIMO-2274:
-
Assignee: Vamsavardhana Reddy
> realm-principal does not work in web app security
> ---
+1 to committing it from me
thanks
david jencks
On Aug 21, 2006, at 6:47 PM, Jason Dillon wrote:
Anyone object if I commit this to trunk?
Its been siting in my workspace for a few days, no comments so far...
I think it is important that we have control over these artifacts
we include.
--
On Aug 21, 2006, at 7:13 PM, Kevan Miller wrote:
I think the source of complexity is the granularity of versioning
we're trying to apply to specs... I wonder if the simplest course
of action is to stop releasing individually versioned specs, and
instead always release all specs. When an upda
+1
--kevan
On Aug 18, 2006, at 11:37 AM, Matt Hogstrom wrote:
Given that we are close to completing the M2 conversion and have
some disruptive changes to make to trunk this vote is to capture
the communities input on the structure of the Geronimo repository.
Given that this is about our bui
As long as we have inter-dependencies between specs (e.g. javamail
depends on activation; jaxrpc on saaj, qname, and servlet; and
especially geronimo-spec-j2ee depends on everything), I'm not
convinced that this really makes things any better...
I agree that your plan is better than the pre
Okay, I'm going to commit this.
If anyone see anything strange, like you are using a 1.4 JDK and it
complains please let me know right away and I will fix and/or back-
out this change.
--jason
On Aug 21, 2006, at 5:34 PM, Alan Cabrera wrote:
Thanks for pointing this out for me. It seems
Anyone object if I commit this to trunk?
Its been siting in my workspace for a few days, no comments so far...
I think it is important that we have control over these artifacts we include.
--jason
On 8/20/06, Jason Dillon <[EMAIL PROTECTED]> wrote:
I've got new war's and car's in my workspac
Hello,
GERONIMO-2294
In security realm with multiple login modules, anything after the first is ignored
is categorized as a blocker. It is more than 2 days since I have
submitted patches for this issue. But, I do not see any activity
on this JIRA. I wonder if this J
Thanks for pointing this out for me. It seems like a reasonable idea.
Regards,
Alan
Jason Dillon wrote:
We already have this... this just means that compiles will continue to
gen 1.4 bytecode. Some tests have been known to fail because they
were run with 1.5, and then all that orb stuff. W
[ http://issues.apache.org/jira/browse/GERONIMO-2338?page=all ]
David Jencks closed GERONIMO-2338.
--
I've confirmed that the rars and jars are now included, thanks jason!
> m2 assemblies have no way of getting rars/jars that aren't car dependencies
> into
On Aug 21, 2006, at 4:11 PM, Sachin Patel wrote:
On Aug 21, 2006, at 4:31 PM, Dain Sundstrom wrote:
Thanks. I have a few questions/issues...
Why the separation between resources and classes. Don't we need
to add both to the class loader anyway? I'm curious when this
differentiation is
Matt Hogstrom wrote:
Given that we are close to completing the M2 conversion and have some
disruptive changes to make to trunk this vote is to capture the
communities input on the structure of the Geronimo repository.
Given that this is about our build environment and development
structure fo
[ https://issues.apache.org/activemq/browse/SM-519?page=all ]
Guillaume Nodet resolved SM-519.
Resolution: Fixed
Assignee: Guillaume Nodet
> Update LICENSE and NOTICE files according to
> http://www.apache.org/dev/apply-license.html#license
>
On Aug 21, 2006, at 4:31 PM, Dain Sundstrom wrote:Thanks. I have a few questions/issues...Why the separation between resources and classes. Don't we need to add both to the class loader anyway? I'm curious when this differentiation is important.Ok, This is where I value your input. There could
Hi Matt,
Thanks for having a look at it. As a matter of fact, I have been
pretty useless with respect to reviewing patches; so, it is me who
owes the apologies.
Regarding the work in sandbox, I had a look to it when working on
this patch. Even if I am not relying on it, I think that this
[ http://issues.apache.org/jira/browse/GERONIMO-2338?page=all ]
Jason Dillon resolved GERONIMO-2338.
Resolution: Fixed
This is done. You probably need to clean first, or at the very least:
{noformat}
cd m2-assemblies
mvn clean
{noformat}
> m2 asse
[
http://issues.apache.org/jira/browse/XBEAN-45?page=comments#action_12429557 ]
Guillaume Nodet commented on XBEAN-45:
--
I have made the changes discussed on the mailing list:
* rename the module to "xbean-classloader"
* change package
[ http://issues.apache.org/jira/browse/XBEAN-3?page=all ]
Guillaume Nodet updated XBEAN-3:
Fix Version/s: 2.6
Description: Qdox 1.6 has been released recently, so I will upgrade as
soon as it is available on the m2 repo.
Assignee: Guillaum
[ http://issues.apache.org/jira/browse/DAYTRADER-10?page=all ]
Slava updated DAYTRADER-10:
---
Attachment: FixForDaytrader-10.patch
I've attached the fix.
> Update the import statements of Quote.java and QuoteHome.java
> -
I've seen that before, but I can't understand what's going on or how
to load the XML into the broker (if that's what's meant to be done). I
also can't find any further documentation or find out what's going on
from the code.
Any help would be appreciated.
Regards,
Sepand
On 8/21/06, James Strac
If you can find it and send me a diff...
--jason
On Aug 21, 2006, at 2:44 PM, Guillaume Nodet wrote:
I think that for xbean we already use a patched version of the
export plugin,
but I do not know where it is ...
On 8/21/06, Jason Dillon <[EMAIL PROTECTED]> wrote:
Um, I think we are gonna
Update the import statements of Quote.java and QuoteHome.java
-
Key: DAYTRADER-10
URL: http://issues.apache.org/jira/browse/DAYTRADER-10
Project: DayTrader
Issue Type: Improvement
I think that for xbean we already use a patched version of the export plugin,
but I do not know where it is ...
On 8/21/06, Jason Dillon <[EMAIL PROTECTED]> wrote:
Um, I think we are gonna need to patch the AutoExport plugin to fix
this... since it will also strip out urls in the same "intellige
I think it is fine to use File for now... its simpler... though I'd
still like to entertain the idea of using VFS to abstract all things
file...
--jason
On Aug 21, 2006, at 2:35 PM, Dain Sundstrom wrote:
On Aug 21, 2006, at 1:39 PM, Jason Dillon wrote:
On Aug 21, 2006, at 1:31 PM, Dain
Um, I think we are gonna need to patch the AutoExport plugin to fix
this... since it will also strip out urls in the same "intelligent"
fashion from the sidenav links... all links really.
I will peek at how easy the fix is later today.
--jason
On Aug 21, 2006, at 2:13 PM, Joe Bohn wrote:
opps.. thanks Guillaume!
On 8/18/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Author: gnodet
Date: Fri Aug 18 01:57:12 2006
New Revision: 432530
URL: http://svn.apache.org/viewvc?rev=432530&view=rev
Log:
Add missing class from XBEAN-33
Added:
geronimo/xbean/trunk/xbean-spring-common/s
On Aug 21, 2006, at 1:39 PM, Jason Dillon wrote:
On Aug 21, 2006, at 1:31 PM, Dain Sundstrom wrote:
I think using URLs instead of files, is going to be very
difficult. We had tons of problems dealing with paths containing
spaces and urls. IIRC we had to encode and decode URLs all the
tim
On Aug 21, 2006, at 1:05 PM, David Jencks wrote:
It's pretty obvious where to put jee5 specs, and now I've committed
this one. I was trying to ask where we want to put work on jee5
implementations so they won't interfere with the j2ee 1.4
implementation. I can see two choices:
- if we c
Hi Aaron,
I try to define correct definition for G 1.1. in many ways, but server still
dont't get my definition: (@see citate ). Could you pls publish somewere a
full deployeble HelloJMS.war?
The documentation is everytime is greate, but one example will be more
usefull. 10x a lot!
org.apache.g
#^$% I hate IE.
Anyways, looks like the URL gets rendered as "" when you are on the
page... which is bunk too. Silly AutoExport trying to be smart and
ends up being really dumb.
Thanks for pointing this out... will see what I can do about that...
Also IE wrecks the justification for the
Jason Dillon wrote:
On Aug 21, 2006, at 1:54 PM, Joe Bohn wrote:
I noticed a peculiar thing with the links at the top right of the
banner. It seems like clicking on a link like "Source" functions as
a toggle ... such that if you click it again once there it will take
you back to the hom
[ https://issues.apache.org/activemq/browse/SM-545?page=all ]
Guillaume Nodet resolved SM-545.
Fix Version/s: 3.0-M3
(was: 3.0)
Resolution: Fixed
Author: gnodet
Date: Mon Aug 21 14:09:59 2006
New Revision: 433360
URL: http:
[ https://issues.apache.org/activemq/browse/SM-545?page=all ]
Guillaume Nodet reassigned SM-545:
--
Assignee: Guillaume Nodet (was: Fritz Oconer)
> jbi-maven-plugin throws an error when building a jbi-service-assembly with 2
> or more dependencies using
[
http://issues.apache.org/jira/browse/GERONIMO-2326?page=comments#action_12429532
]
David Jencks commented on GERONIMO-2326:
I've opened a separate issue GERONIMO-2338 for the "get the rars in the repo"
part of this, so I think this is
m2 assemblies have no way of getting rars/jars that aren't car dependencies
into the g repo
---
Key: GERONIMO-2338
URL: http://issues.apache.org/jira/browse/GERONIMO-2338
On Aug 21, 2006, at 1:54 PM, Joe Bohn wrote:
I noticed a peculiar thing with the links at the top right of the
banner. It seems like clicking on a link like "Source" functions
as a toggle ... such that if you click it again once there it will
take you back to the home page. This is also tr
+1
John
Matt Hogstrom wrote:
Given that we are close to completing the M2 conversion and have some
disruptive changes to make to trunk this vote is to capture the
communities input on the structure of the Geronimo repository.
Given that this is about our build environment and development
str
[
https://issues.apache.org/activemq/browse/AMQ-888?page=comments#action_36819 ]
Hiram Chirino commented on AMQ-888:
---
Added a few more headers
* in trunk rev 433353
* in 4.0 branch rev 433354
> Licence headers missing from several source files
Look good Jason.
I noticed a peculiar thing with the links at the top right of the
banner. It seems like clicking on a link like "Source" functions as a
toggle ... such that if you click it again once there it will take you
back to the home page. This is also true of "Download" and "Mailing
On Aug 21, 2006, at 1:31 PM, Dain Sundstrom wrote:
Why the separation between resources and classes. Don't we need to
add both to the class loader anyway? I'm curious when this
differentiation is important.
From the deployers perspective, they just need to get added to the
classpath... s
Thanks. I have a few questions/issues...
Why the separation between resources and classes. Don't we need to
add both to the class loader anyway? I'm curious when this
differentiation is important.
I think using URLs instead of files, is going to be very difficult.
We had tons of probl
[
http://issues.apache.org/jira/browse/GERONIMO-2326?page=comments#action_12429517
]
David Jencks commented on GERONIMO-2326:
Forgot to add that jdillon is working on including these artifacts in the m2
assemblies.
> unable to deploy a
[ http://issues.apache.org/jira/browse/GERONIMO-2326?page=all ]
David Jencks reassigned GERONIMO-2326:
--
Assignee: David Jencks (was: Alan Cabrera)
> unable to deploy a database pool
>
>
> Key: GERONI
FYI @return with no args is not a valid javadoc tag. :-PAlso, not sure that getURI() should return a string... maybe getURI() is not the right name, I'd expect a method like that to return a URI instance. But overall, I think that if this interface will allow IDE plugins the intel they need then th
[
http://issues.apache.org/jira/browse/GERONIMO-2326?page=comments#action_12429516
]
David Jencks commented on GERONIMO-2326:
I'd like to reiterate that adding rars as a dependency is totally unacceptable
and I am firmly -1 on anything
If I can dig up my copy of photoshop I might be able to craft
something...
--jason
On Aug 21, 2006, at 1:00 PM, Dain Sundstrom wrote:
Very cool!
On Aug 21, 2006, at 12:07 PM, Jason Dillon wrote:
Probably best to get a new graphic that incorporates the G and
XBean elements. Might need t
Doh, sorry, guess some javadoc would help :)... So basically the idea is to be able to represent a deployable object, that can be either a jar, or some custom structure specific to a given IDE/build environemnt.public interface DeployableModule { /** * uri of the module, foo.ear, if a nested modu
It's pretty obvious where to put jee5 specs, and now I've committed
this one. I was trying to ask where we want to put work on jee5
implementations so they won't interfere with the j2ee 1.4
implementation. I can see two choices:
- if we can run the j2ee 1.4 tck with jee5 spec jars, we cou
Very cool!
On Aug 21, 2006, at 12:07 PM, Jason Dillon wrote:
Probably best to get a new graphic that incorporates the G and
XBean elements. Might need to get some help from Epiq to get a
updated layout that allows use to use the same theme across sub-
projects & the main site.
I'd love t
Some java docs would help me understand what these methods are
supposed to do.
-dain
On Aug 21, 2006, at 10:53 AM, Sachin Patel wrote:
For the following JIRA, where all the module builders assume a jar
file, what if we change all methods that take a JarFile to
something like the following
You can put it here for now http://svn.apache.org/repos/asf/geronimo/
specs/branches/jee5_exp/
When Jason's done with the new spec layout, I'll be working on moving
those in to trunk.
-David
On Aug 20, 2006, at 5:41 PM, David Jencks wrote:
I've implemented the jta 1.1 feature locally and w
On 8/21/06, Jason Dillon <[EMAIL PROTECTED]> wrote:
I've just finished the initial re-theme-ification of the XBean site
to use the AutoExport template we are using for GMOxSITE.
It will eventually make it to:
http://geronimo.apache.org/xbean
but for now you can see what it looks like here
Amazing !
Thx a lot, Jason.
On 8/21/06, Jason Dillon <[EMAIL PROTECTED]> wrote:
I've just finished the initial re-theme-ification of the XBean site
to use the AutoExport template we are using for GMOxSITE.
It will eventually make it to:
http://geronimo.apache.org/xbean
but for now you ca
[
http://issues.apache.org/jira/browse/GERONIMO-2332?page=comments#action_12429499
]
David Jencks commented on GERONIMO-2332:
I don't think we can type the schemas up without typos that will change the
meaning compared to the sun schema
I'd also drop the public modifier for methods... its redundant ;-)--jasonOn Aug 21, 2006, at 10:53 AM, Sachin Patel wrote:For the following JIRA, where all the module builders assume a jar file, what if we change all methods that take a JarFile to something like the following?public interface IDepl
Yeah, it sounds better.
On 8/21/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
I prefer we don't use a plural for a module or package name, so how
about we call the module xbean-classloader?
-dain
On Aug 20, 2006, at 12:13 PM, Guillaume Nodet wrote:
> Should the xbean-classloaders module have
Oh, I also dropped the search for now... its not very good at
actually searching the content of the space :-(
--jason
On Aug 21, 2006, at 12:07 PM, Jason Dillon wrote:
I've just finished the initial re-theme-ification of the XBean site
to use the AutoExport template we are using for GMOxSI
I've just finished the initial re-theme-ification of the XBean site
to use the AutoExport template we are using for GMOxSITE.
It will eventually make it to:
http://geronimo.apache.org/xbean
but for now you can see what it looks like here:
http://xbean.goopen.org
* * *
A few things
On Aug 21, 2006, at 2:18 PM, Jason Dillon wrote:Minus the "I" prefix... seems okay. What about using URLs instead of Files?Yep, agree.--jasonOn Aug 21, 2006, at 10:53 AM, Sachin Patel wrote:For the following JIRA, where all the module builders assume a jar file, what if we change all methods that
Great, thanks for letting us know.
On 8/21/06, Aaron Mulder <[EMAIL PROTECTED]> wrote:
On 8/21/06, James Strachan <[EMAIL PROTECTED]> wrote:
> It doesn't look too good closing the session inside a MessageListener
> - any chance you could change that code?
OK, I tried registering the JMS objects
On 8/21/06, James Strachan <[EMAIL PROTECTED]> wrote:
It doesn't look too good closing the session inside a MessageListener
- any chance you could change that code?
OK, I tried registering the JMS objects with a different thread that
will then wake up and close them, and that seems to work fine
Sure if you want to wait 0-6 months for a response.
-dain
On Aug 21, 2006, at 11:00 AM, Alan D. Cabrera wrote:
Can we go back to the root of the problem which is the distribution
of the schemas? This may have already been put to bed but, can't
we get permission from Sun to distribute these
[ http://issues.apache.org/jira/browse/GERONIMO-2326?page=all ]
Alan Cabrera updated GERONIMO-2326:
---
Fix Version/s: 1.1.2
1.2
Affects Version/s: 1.1.2
Assignee: Alan Cabrera
> unable to deploy a database pool
I prefer we don't use a plural for a module or package name, so how
about we call the module xbean-classloader?
-dain
On Aug 20, 2006, at 12:13 PM, Guillaume Nodet wrote:
Should the xbean-classloaders module have a package named
org.apache.xbean.classloaders
instead of keeping the old one
[ http://issues.apache.org/jira/browse/GERONIMO-2327?page=all ]
Alan Cabrera resolved GERONIMO-2327.
Resolution: Fixed
> Need to encode colons for JACC web permissions
> --
>
> Key: GERONIMO
On 8/21/06, Aaron Mulder <[EMAIL PROTECTED]> wrote:
I ran a test where one publisher sent 10 messages to a topic with 500
connected subscribers (run as 500 threads from a single VM, but in a
different VM than the producer). Each consumer knows how many
messages to expect, and tries to shut down
Minus the "I" prefix... seems okay. What about using URLs instead of Files?--jasonOn Aug 21, 2006, at 10:53 AM, Sachin Patel wrote:For the following JIRA, where all the module builders assume a jar file, what if we change all methods that take a JarFile to something like the following?public inter
On 8/21/06, Jason Dillon <[EMAIL PROTECTED]> wrote:
Just nuke the old wiki and be done with it already...
+1 (no need to keep it until crawlers or any spiders or so will have
the links updated)
Jacek
--
Jacek Laskowski
http://www.laskowski.net.pl
[
http://issues.apache.org/jira/browse/GERONIMO-2332?page=comments#action_12429482
]
Alan Cabrera commented on GERONIMO-2332:
Wow, if we could do this and it will fly with Sun, then this is *THE* way to go.
> RTC Put the generated xmlbe
I ran a test where one publisher sent 10 messages to a topic with 500
connected subscribers (run as 500 threads from a single VM, but in a
different VM than the producer). Each consumer knows how many
messages to expect, and tries to shut down once it receives the last
message. The consumers wer
[
http://issues.apache.org/jira/browse/GERONIMO-2332?page=comments#action_12429479
]
Matt Hogstrom commented on GERONIMO-2332:
-
I like this approach but it sounds like there are some kinks to be worked out.
What if we re-type the spec
Can we go back to the root of the problem which is the distribution of
the schemas? This may have already been put to bed but, can't we get
permission from Sun to distribute these puppies?
Regards,
Alan
Dain Sundstrom wrote:
Why not publish the src jar in addition to the binary?
-dain
On
Just nuke the old wiki and be done with it already...
:-\
--jason
On Aug 21, 2006, at 6:44 AM, Paul McMahan wrote:
Good idea Cameron.
On 8/20/06, Cameron Braid <[EMAIL PROTECTED]> wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
building geronimoPaul McMahan wrote:
> +1 I'm all in f
For the following JIRA, where all the module builders assume a jar file, what if we change all methods that take a JarFile to something like the following?public interface IDeployableModule { public String getURI(); public File getRoot(); public File[] getResourceFolders(); public File[] getClass
You know you can add this to ~/.subversion/config so you don't need
to add this to all directories... right?
--jason
On Aug 21, 2006, at 10:41 AM, [EMAIL PROTECTED] wrote:
Author: dain
Date: Mon Aug 21 10:41:41 2006
New Revision: 433304
URL: http://svn.apache.org/viewvc?rev=433304&view=rev
[
http://issues.apache.org/jira/browse/GERONIMO-2332?page=comments#action_12429472
]
Alan Cabrera commented on GERONIMO-2332:
Agreed. This is starting to look like the tail is wagging the dog. What is
the problem that we are trying to
On 8/21/06, Sepand M <[EMAIL PROTECTED]> wrote:
Actually, a text based map would be redundant if there's an XML map
already in place.
I can't seem to find the XML map anywhere. Could you tell me where it is?
See the exampe here...
http://incubator.apache.org/activemq/security.html
--
James
--
Actually, a text based map would be redundant if there's an XML map
already in place.
I can't seem to find the XML map anywhere. Could you tell me where it is?
Thanks,
Sepand
On 8/21/06, James Strachan <[EMAIL PROTECTED]> wrote:
Sounds good to me :). We've got the XML based one but by all means
[
https://issues.apache.org/activemq/browse/AMQ-888?page=comments#action_36818 ]
Hiram Chirino commented on AMQ-888:
---
added a bunch of licence headers
* in trunk in rev 433286
* in 4.0 branch in rev 433295
> Licence headers missing from se
Why not publish the src jar in addition to the binary?
-dain
On Aug 21, 2006, at 9:56 AM, David Jencks wrote:
I've thought about this some more and have some major reservations
about this approach.
- The generated code wont have apache headers, so we can't actually
check in into svn. The
[ https://issues.apache.org/activemq/browse/AMQ-888?page=all ]
Hiram Chirino updated AMQ-888:
--
Attachment: findunlicensed.pl
Using the attached perl script to find the source files that do not have a
licence header attached.
> Licence headers missing from
Licence headers missing from several source files.
--
Key: AMQ-888
URL: https://issues.apache.org/activemq/browse/AMQ-888
Project: ActiveMQ
Issue Type: Bug
Affects Versions: 4.0
I've thought about this some more and have some major reservations
about this approach.
- The generated code wont have apache headers, so we can't actually
check in into svn. There might be a way to fix this with a script of
some kind.
- More seriously, this will eliminate traceability t
[
http://issues.apache.org/jira/browse/GERONIMO-2332?page=comments#action_12429452
]
David Jencks commented on GERONIMO-2332:
Theres a fairly serious problem with this proposal in that it involves
generating source code that does not th
On Aug 21, 2006, at 6:55 AM, Matt Hogstrom wrote:
Jason Dillon wrote:
PROPOSAL:
1. Each spec will no longer be split up into trunk+branches+tags.
There will instead be one trunk+branches+tags for all specs laid
out as follows:
specs/trunk/pom.xml
specs/trunk/
specs/tags/-
s
[ http://issues.apache.org/jira/browse/GERONIMO-2275?page=all ]
Vamsavardhana Reddy updated GERONIMO-2275:
--
Affects Version/s: 1.1.1
> login-domain-principal or realm-principal in default-principal cause
> deployment errors
> --
[
http://issues.apache.org/jira/browse/GERONIMO-2275?page=comments#action_12429437
]
Vamsavardhana Reddy commented on GERONIMO-2275:
---
Verified the fix in branches 1.1. Fix is needed in 1.1.1 too.
> login-domain-principal or realm
[X] +1 Allow changes
Joe
Jason Dillon wrote:
PROPOSAL:
1. Each spec will no longer be split up into trunk+branches+tags.
There will instead be one trunk+branches+tags for all specs laid out as
follows:
specs/trunk/pom.xml
specs/trunk/
specs/tags/-
specs/branches/
2.
1 - 100 of 151 matches
Mail list logo
