Menu
▾
▴
jboss-dev-forums — The jboss development forum posts
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
(157) |
May
(789) |
Jun
(608) |
Jul
(554) |
Aug
(868) |
Sep
(654) |
Oct
(994) |
Nov
(803) |
Dec
(982) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(1006) |
Feb
(1054) |
Mar
(1345) |
Apr
(1305) |
May
(1392) |
Jun
(1016) |
Jul
(265) |
Aug
(1) |
Sep
(8) |
Oct
(9) |
Nov
(8) |
Dec
(19) |
| 2007 |
Jan
(20) |
Feb
(10) |
Mar
(20) |
Apr
(8) |
May
(4) |
Jun
(1) |
Jul
(6) |
Aug
(3) |
Sep
(6) |
Oct
(12) |
Nov
(7) |
Dec
(13) |
| 2008 |
Jan
(5) |
Feb
(4) |
Mar
(34) |
Apr
(32) |
May
(22) |
Jun
(21) |
Jul
(30) |
Aug
(18) |
Sep
(30) |
Oct
(23) |
Nov
(86) |
Dec
(51) |
| 2009 |
Jan
(25) |
Feb
(26) |
Mar
(34) |
Apr
(47) |
May
(38) |
Jun
(25) |
Jul
(36) |
Aug
(9) |
Sep
(8) |
Oct
(10) |
Nov
(4) |
Dec
(17) |
| 2010 |
Jan
(7) |
Feb
(9) |
Mar
(26) |
Apr
(49) |
May
(52) |
Jun
(48) |
Jul
(39) |
Aug
(27) |
Sep
(9) |
Oct
(14) |
Nov
(7) |
Dec
(10) |
| 2011 |
Jan
(12) |
Feb
(9) |
Mar
(17) |
Apr
(33) |
May
(39) |
Jun
(36) |
Jul
(29) |
Aug
(26) |
Sep
(29) |
Oct
(38) |
Nov
(35) |
Dec
(27) |
| 2012 |
Jan
(20) |
Feb
(34) |
Mar
(29) |
Apr
(33) |
May
(45) |
Jun
(46) |
Jul
(50) |
Aug
(35) |
Sep
(55) |
Oct
(68) |
Nov
(79) |
Dec
(45) |
| 2013 |
Jan
(67) |
Feb
(20) |
Mar
(55) |
Apr
(52) |
May
(25) |
Jun
(25) |
Jul
(34) |
Aug
(27) |
Sep
(21) |
Oct
(21) |
Nov
(19) |
Dec
(12) |
| 2014 |
Jan
(10) |
Feb
(8) |
Mar
(13) |
Apr
(18) |
May
(36) |
Jun
(26) |
Jul
(17) |
Aug
(19) |
Sep
(13) |
Oct
(8) |
Nov
(7) |
Dec
(5) |
| 2015 |
Jan
(11) |
Feb
(2) |
Mar
(13) |
Apr
(15) |
May
(7) |
Jun
(2) |
Jul
(4) |
Aug
(3) |
Sep
(3) |
Oct
|
Nov
(2) |
Dec
(1) |
| 2016 |
Jan
(3) |
Feb
(5) |
Mar
(19) |
Apr
(34) |
May
(9) |
Jun
(10) |
Jul
(5) |
Aug
(10) |
Sep
(5) |
Oct
(11) |
Nov
(19) |
Dec
(7) |
| 2017 |
Jan
(4) |
Feb
(4) |
Mar
(8) |
Apr
(5) |
May
(12) |
Jun
(5) |
Jul
(11) |
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <sco...@jb...> - 2005-07-27 16:40:40
|
It was simply to add support to Properties type of attributes before there was consistent processing of any xml text at the SARDeployer level. It should have been added to the SARDeployer at that point. Now, as the SARDeployer gets migrated to using jbossxb, it should be delegated to the jbossxb layer. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886811#3886811 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886811 |
|
From: <rl...@jb...> - 2005-07-27 16:35:39
|
The two issues raised, to reiterate some posts that didn't make it into the forum are: 1) Eclipse classpath generation 2) The download of dependencies to path structure with a version number Eclipse classpath generation is a difficult concept for this "hybrid" build. I use the word hybrid in terms that it is mostly buildmagic with a bit of jbossbuild. The jbossbuild is the portion which is responsible for downloading the dependencies. Keep in mind that the jbossbuild at this point essentially only has a list of dependencies which it knows about, however it does not have any concept of modules or which dependencies are required by each module. In order to properly generate an eclipse classpath file for each module we would need the information defined in the buildmagic system (e.g. which modules, which depedencies). anonymous wrote : I would guess its not a big deal to simply drop the local repository version info. The generated get ouput location and local path checks would simply drop the version portion. The libraries.ent generation would also need to be updated. Dropping the local version information shouldn't be tough. I will begin work on it today. If we are to drop the local version info from the paths, this will give us a very similiar thirdparty folder as to what was being checked out from cvs. In this case, even if no eclipse classpath is generated, aren't we basically at the same point we are with the standard buildmagic build as far as classpath information is concerned? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886809#3886809 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886809 |
|
From: ejain <nu...@jb...> - 2005-07-27 16:29:02
|
That seems to help! Opened an issue for this: http://jira.jboss.com/jira/browse/JBAOP-160 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886833#3886833 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886833 |
|
From: ereze <nu...@jb...> - 2005-07-27 16:25:30
|
Hi, My application code is working with XDoclet and I wish to make use of the left-join read ahead strategy. Is there a way to go around it? May a merged file ? Thanks in advance, Erez View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886852#3886852 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886852 |
|
From: ejain <nu...@jb...> - 2005-07-27 16:23:54
|
The full text of the warning is: [aopc] [warning] Trying to compile C:\Documents and Settings\Eric\My Documents\Projects\Aspects\build\test\ObjectHolder.class and found it also within file:/C:/Documents%20and%20Settings/Eric/My%20Documents/Projects/Aspects/build/test/ObjectHolder.class will not proceed. So the file does seem to be the same, but somehow it's twice in the classpath (or whatever), with different but equivalent syntax! Currently I have this in the aopc task: <classpath path="build"/> | <src path="build"/> What's the difference between the "classpath" and the "src" element? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886823#3886823 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886823 |
|
From: <kab...@jb...> - 2005-07-27 16:21:23
|
Try putting your project in a directory without spaces in the path name. Docu for the ant task: http://docs.jboss.com/aop/1.3/aspect-framework/reference/en/html/compiling.html#ant View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886827#3886827 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886827 |
|
From: <ste...@jb...> - 2005-07-27 16:16:48
|
Follow-on question: Does this neccessarily need to happen from The Hibernate MBean's startService()? Specifically, the Thread.currentThread().getContextClassLoader() part... The MBean gives the user a managed operation to rebuild the SessionFactory; both this and the startService() go through an internal method named buildSessionFactory(). Would it be safe to have the Thread.currentThread().getContextClassLoader() call in that method, such that rebuilding the session factory could potentially "notice" added/removed domain classes? I guess this would depend upon whether subsequent calls into the MBean (aka, the rebuildSessionFactory() managed operation) would be executed on a thread which has the same "URL visibility" as the one from startService(); is this always the case (at least as long as the request is made through the JMX container)? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886850#3886850 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886850 |
|
From: dnatobyte <nu...@jb...> - 2005-07-27 16:14:43
|
I'm currently running Tomcat 5.0.28 and am receiving the following stack trace during startup
**************
July 15, 2005 9:09:45 PM org.apache.commons.modeler.Registry registerComponent
SEVERE: Error registering Catalina:type=RequestProcessor,worker=http-8080,name=HttpRequest2
java.security.AccessControlException: Access denied (mx4j.server.MBeanTrustPermission register): MBean class org.apache.commons.modeler.BaseModelMBean is not trusted for registration
at mx4j.server.interceptor.SecurityMBeanServerInterceptor.checkTrustRegistration(SecurityMBeanServerInterceptor.java:156)
at mx4j.server.interceptor.SecurityMBeanServerInterceptor.registration(SecurityMBeanServerInterceptor.java:116)
at mx4j.server.interceptor.DefaultMBeanServerInterceptor.registration(DefaultMBeanServerInterceptor.java:113)
at mx4j.server.interceptor.DefaultMBeanServerInterceptor.registration(DefaultMBeanServerInterceptor.java:113)
at mx4j.server.interceptor.ContextClassLoaderMBeanServerInterceptor.registration(ContextClassLoaderMBeanServerInterceptor.java:108)
at mx4j.server.MBeanServerImpl.registerImpl(MBeanServerImpl.java:1051)
at mx4j.server.MBeanServerImpl.registerMBeanImpl(MBeanServerImpl.java:1002)
at mx4j.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:978)
at org.apache.commons.modeler.Registry.registerComponent(Registry.java:871)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.init(Http11Protocol.java:670)
at org.apache.tomcat.util.net.TcpWorkerThread.getInitData(PoolTcpEndpoint.java:527)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:672)
at java.lang.Thread.run(Thread.java:534)
**************
It appears to be a policy issue, but as far as I know no one has manipulated the default policy settings in catalina.policy.
Has anyone else observed this specific security exception and if so, was there a solution to the problem.
Thanks in advance,
Jeff Barton
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886821#3886821
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886821
|
|
From: milesif <nu...@jb...> - 2005-07-27 16:12:43
|
Hi kabir, I forgot to say that I already did what is indicated in section "10.3.3. JBoss 4.x and JDK 5" of manual, setting -javaagent:pluggable-instrumentor.jar and copying pluggable-instrumentor.jar in the bin directory. I also enabled loadtime weaving (not used by ejb3 as tou explained to me). You mean I can never set my aspects for ejb3 ? or I can do that modifying configuration in the all/deploy/jboss-aop-jdk50.deployer/base-aop.xml file ? Anyway note that in the annotated-injboss example there are no ejb3, but I can set aspects neither for servlets nor for ejbs 2. I do not think that ejb3 disable aop for other components. There must be something else I miss but I cannot see what. Thanks a lot Francesco Milesi View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886837#3886837 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886837 |
|
From: <aco...@jb...> - 2005-07-27 16:07:35
|
Guys,
What do you think of this?
Mailbox support should be refactored such that folders look like this
joe/
inbox/
foo/
andy/
inbox/
spam/
foo-doo/
UserRepository will now need to support properties for users:
String user = "andy";
String password = "yeahright";
boolean b = ur.authenticate(user, password);
boolean b = ur.authorize(user, "andy-inbox-create");
String s = ur.defaultFolder(user);
(s.equals("andy/inbox") == true)
POP should be bound to defaultFolder. Default listeners will route SMTP mail to the defaultFolder.
Mailbox will need to change dramatically:
folders can contain other folders.
folders contain attributes:
create-roles
write-roles
delete-roles
roles are additive, meaning if andy/inbox has two roles for create-roles (andy-inbox-create, inbound-smtp-create) then users
having either role will be automatically able to create mails in that mail box.
UserRepository should have an "unauthenticatedUser" which has some default roles (inbound-smtp-create). SMTP should check this
user with no/any password when a user runs any supported command after HELO except for AUTH.
Any way we could do this using aspects or chains?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886795#3886795
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886795
|
|
From: <kab...@jb...> - 2005-07-27 15:52:21
|
Make sure that you have included org.jboss.injbossaop in the Include attribute of the AspectManager service and that you are using AspectManagerServiceJDK5 as outlined here http://www.jboss.org/index.html?module=bb&op=viewtopic&t=66619 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886844#3886844 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886844 |
|
From: <kab...@jb...> - 2005-07-27 12:16:13
|
It looks like you have the same .class files defined in several locations. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886778#3886778 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886778 |
|
From: omkar.prabhune <nu...@jb...> - 2005-07-27 10:32:52
|
i am using jboss-3.2.2 as a ejb container.i am new in ejb field. i have run some of the workbook example properly. i want to use jsp/servlet using tomcat in jboss. how should i begin. . where i put jsp/servelet pages. plz give me sample examples of jsp/servet using tomcat. i know jsp & servlet. plz help me. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886766#3886766 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886766 |
|
From: <kab...@jb...> - 2005-07-27 10:29:56
|
The issues are that infinite recursion can take place, since interceptors/aspects themselves can be weaved. I tried something similar to what you describe above based on one of the examples in our tutorials, but could not reproduce your problem. | <bind pointcut="call(* *->*(..))"> | <interceptor class="SimpleInterceptor"/> | </bind> | causes recursion as expected | <bind pointcut="call(* *->*(..)) AND !within(SimpleInterceptor)"> | <interceptor class="SimpleInterceptor"/> | </bind> | was fine. Do you have other bindings declared in your jboss-aop.xml file? If you do, and haven't already, make sure that all your interceptors/aspects are included in !within() clauses View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886765#3886765 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886765 |
|
From: ejain <nu...@jb...> - 2005-07-27 10:23:34
|
I have this in my build file: <aopc compilerclasspathref="classpath" verbose="true"> | <classpath path="build"/> | <src path="build"/> | <include name="**/*.class"/> | <aoppath path="jboss-aop.xml"/> | </aopc> "classpath" contains all jars. I get: [aopc] [debug] jboss.aop.class.path is NULL | [aopc] [debug] jboss.aop.search.classpath: 'null' true | [aopc] [debug] jboss.aop.path: jboss-aop.xml | [aopc] jboss.aop.path[0]: jboss-aop.xml | [aopc] [deploying] jboss-aop.xml | [aopc] [warning] Trying to compile [...]\build\test\ObjectHolder.class and found it also within [...]\build/test/ObjectHolder.class will not proceed. | [aopc] [warning] Trying to compile [...]\build\test\ObjectInterceptor.class and found it also within [...]/build/test/ObjectInterceptor.class will not proceed. | [aopc] Build Successful: 219 ms Any idea what is going wrong here? I can post my classes and aspect configuration etc, but I suspect there is a more fundamental issue here... View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886764#3886764 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886764 |
|
From: oberon777 <nu...@jb...> - 2005-07-27 08:57:19
|
Let me add the following: suppose I am only interested in collecting all the classes used at runtime for a given Web app. Is there a way to do that? AOP seemed like the way to go, but I am sure there are other mechanisms like playing classloader games, etc. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886750#3886750 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886750 |
|
From: oberon777 <nu...@jb...> - 2005-07-27 08:35:01
|
Kabir, thanks for your reply. Yeah, those belong to the default package. Those pointcuts are intentially wide, narrowing them down is not really an option. Should I assume that matching on every method or even every constructor call is not likely to work? What exactly are the issues you're referring to?.. On a related note, I was talking to JBossProfiler folks and was given the impression that they succeed with using AOP for getting profile information. Getting profile info most definitely requires having a large number of pointcuts... I wouldn't be surpised if these same issues arose for even a small application. I should probably double-check with a smaller test case. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886745#3886745 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886745 |
|
From: <kab...@jb...> - 2005-07-27 08:20:35
|
We do have some isues with wide pointcuts like these, and opinion is divided whether this is by design or not. Assuming your CallerInterceptor and StackTraceCatcher classes are not within the default package, try fully qualifying their names. Otherwise try narrowing down the pointcut View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886742#3886742 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886742 |
|
From: <dim...@jb...> - 2005-07-27 08:00:54
|
Do you remember what was the original need for PropertiesEditor doing the replacement? From cvs I see this is done since 3.2.4 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886739#3886739 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886739 |
|
From: oberon777 <nu...@jb...> - 2005-07-27 05:39:07
|
Please do point me to the relevant code. I am also very curious to see what kind of interceptors you used. If they work just the same, I'd probably prefer to use them. I looked through the files included in the RC1 distribution, but couldn't find any jboss-aop XML pointcut descriptors. Or if you already dump the information I need in the log produced from the profiler, I could definitely use that. Thanks. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886729#3886729 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886729 |
|
From: oberon777 <nu...@jb...> - 2005-07-27 05:30:07
|
A wide pointcut like this yields this problem: | <bind pointcut="call(* org.jgap.*->*(..)) AND !within(CallerInterceptor) AND !within(StackTraceCatcher)"> | <interceptor class="CallerInterceptor"/> | </bind> | Similarly, if I were to have call(* *->*(..)) as the matching expression, the same issue would arise. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886728#3886728 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886728 |
|
From: <sco...@jb...> - 2005-07-27 05:18:04
|
If its to be consistent, I think only the first layer that does the processing of the deployment layer should be doing any transformation of the values. As such, the current parsing of property references by the jboss PropertiesEditor is also incorrect and is a source of another double parse issue. http://jira.jboss.com/jira/browse/JBAS-1888 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886726#3886726 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886726 |
|
From: Scott M S. <sco...@jb...> - 2005-07-27 04:11:01
|
I would guess its not a big deal to simply drop the local repository version info. The generated get ouput location and local path checks would simply drop the version portion. The libraries.ent generation would also need to be updated. I did just try a new clean checkout/build of the latest jboss-4.0.x and its building ok on the dev03 machine. > -----Original Message----- > From: jbo...@li...=20 > [mailto:jbo...@li...] On=20 > Behalf Of Adrian Brock > Sent: Tuesday, July 26, 2005 9:02 PM > To: Nukes Forum > Cc: jbo...@li... > Subject: Re: [Jboss-dev-forums] [Design of JBoss Build=20 > System] - Re: JBossThird Party Build >=20 > Since the forums are down... >=20 > The way I had it discussed with Ryan was that thirdparty=20 > would be something like: >=20 > thirdparty/component/lib/some.jar > thirdparty/component/component-info.xml >=20 > That way it looks "the same" or at least similar whether the=20 > component is checked out in thirdparty or as a source build=20 > and the artifcats in output.=20 > The difference being no source or intermediate objects for=20 > the binary checkout. >=20 > It also means that a component can say "I use log4j and I=20 > don't care what version I compile over. The versions I have=20 > been tested over are in the manifest of my jar in the repository." >=20 > It is then upto the top level build to decide what "branch",=20 > "stability criteria" or explicit version to use, either=20 > through the main build or local user preferences/overrides. >=20 > IIRC we ditched the idea of letting each component take some=20 > kind of "vote" > on which version to use for dependencies and went for the top=20 > level build decides. > Though that decision does not have to be an explicit version.=20 > It could be LATEST-INTEGRATION-TESTED, LATEST-THAT-COMPILES,=20 > BLEEDING-EDGE, etc. >=20 > On Tue, 2005-07-26 at 23:45, sco...@jb... wrote: > > I thought we were going to generate the eclipse library=20 > classpath. The same issue applies to intellij projects=20 > though. These should be generated anyway as the transitive=20 > closure of dependencies is still a function of the version=20 > whether or not its included in the path. > >=20 > > If the thirdparty version info is thrown away, isn't there=20 > an inconsistency in treatment of local vs remote repository=20 > in terms of identifying if a component is up to date? If I=20 > update the local thirdparty component to a newer version? > >=20 > >=20 > >=20 > > View the original post :=20 > >=20 > = http://www.jboss.org/index.html?module=3Dbb&op=3Dviewtopic&p=3D3886720#38= 867 > > 20 > >=20 > > Reply to the post :=20 > >=20 > = http://www.jboss.org/index.html?module=3Dbb&op=3Dposting&mode=3Dreply&p=3D= 3886 > > 720 > >=20 > >=20 > > ------------------------------------------------------- > > SF.Net email is sponsored by: Discover Easy Linux Migration=20 > Strategies=20 > > from IBM. Find simple to follow Roadmaps, straightforward articles,=20 > > informative Webcasts and more! Get everything you need to get up to=20 > > speed, fast. = http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclick > > _______________________________________________ > > Jboss-dev-forums mailing list > > Jbo...@li... > > https://lists.sourceforge.net/lists/listinfo/jboss-dev-forums > -- > xxxxxxxxxxxxxxxxxxxxxxxx > Adrian Brock > Chief Scientist > JBoss Inc. > xxxxxxxxxxxxxxxxxxxxxxxx=20 >=20 >=20 >=20 > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration=20 > Strategies from IBM. Find simple to follow Roadmaps,=20 > straightforward articles, informative Webcasts and more! Get=20 > everything you need to get up to speed, fast.=20 > http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclick > _______________________________________________ > Jboss-dev-forums mailing list > Jbo...@li... > https://lists.sourceforge.net/lists/listinfo/jboss-dev-forums >=20 |
|
From: Adrian B. <adr...@jb...> - 2005-07-27 04:02:27
|
Since the forums are down... The way I had it discussed with Ryan was that thirdparty would be something like: thirdparty/component/lib/some.jar thirdparty/component/component-info.xml That way it looks "the same" or at least similar whether the component is checked out in thirdparty or as a source build and the artifcats in output. The difference being no source or intermediate objects for the binary checkout. It also means that a component can say "I use log4j and I don't care what version I compile over. The versions I have been tested over are in the manifest of my jar in the repository." It is then upto the top level build to decide what "branch", "stability criteria" or explicit version to use, either through the main build or local user preferences/overrides. IIRC we ditched the idea of letting each component take some kind of "vote" on which version to use for dependencies and went for the top level build decides. Though that decision does not have to be an explicit version. It could be LATEST-INTEGRATION-TESTED, LATEST-THAT-COMPILES, BLEEDING-EDGE, etc. On Tue, 2005-07-26 at 23:45, sco...@jb... wrote: > I thought we were going to generate the eclipse library classpath. The same issue applies to intellij projects though. These should be generated anyway as the transitive closure of dependencies is still a function of the version whether or not its included in the path. > > If the thirdparty version info is thrown away, isn't there an inconsistency in treatment of local vs remote repository in terms of identifying if a component is up to date? If I update the local thirdparty component to a newer version? > > > > View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886720#3886720 > > Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886720 > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > Jboss-dev-forums mailing list > Jbo...@li... > https://lists.sourceforge.net/lists/listinfo/jboss-dev-forums -- xxxxxxxxxxxxxxxxxxxxxxxx Adrian Brock Chief Scientist JBoss Inc. xxxxxxxxxxxxxxxxxxxxxxxx |
|
From: <sco...@jb...> - 2005-07-27 03:45:15
|
I thought we were going to generate the eclipse library classpath. The same issue applies to intellij projects though. These should be generated anyway as the transitive closure of dependencies is still a function of the version whether or not its included in the path. If the thirdparty version info is thrown away, isn't there an inconsistency in treatment of local vs remote repository in terms of identifying if a component is up to date? If I update the local thirdparty component to a newer version? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886720#3886720 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886720 |
1965 messages has been excluded from this view by a project administrator.
