February 2008 - jboss-dev-forums - Jboss List Archives

[Design the new POJO MicroContainer] - Re: Update the relevant .classpath files

by ALRubinger

"adrian(a)jboss.org" wrote : We'll continue to disagree. I'm OK with that. :) But I would like to come to a conclusion here (one way or the other) as I'm sometimes unsure how to best maintain my projects' builds. "adrian(a)jboss.org" wrote : It's called an I(ntegrated)DE for a reason ...so we should account for Eclipse's shortcomings in the repo? "adrian(a)jboss.org" wrote : Remembering and performing recipes of many tool procedures is not productive You're going to have to do it anyway whenever you make changes to the dependencies. "adrian(a)jboss.org" wrote : Redundancy is only a problem when it leads to error or reduced performance This is the root of my concern; an Eclipse user with an outdated classpath. "adrian(a)jboss.org" wrote : Checking in the eclipse files in svn makes little difference in practice unless everybody updates them you have to run mvn eclipse:eclipse anyway. Exactly! I'm banking on "not everyone updating", meaning you'd have to run eclipse:eclipse anyway. The difference is one of precedent; by not committing .classpath you EXPECT to have to make this step, not wondering why the build is broken. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133314#4133314 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133314

16 years, 10 months

1
0
0 / 0

[Design of OSGi Integration] - Re: Logging and Exception Handling

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : org.jboss.test.bundle.support.TestVFSDeploymentUnit.getFile(TestVFSDeploymentUnit.java:83) | While we are on the subject, although mocking is a good way of testing in isolation, it's actually worthless in this case. You're testing a facade already. A facade to a mock won't tell you whether it works against the real impl, you can just "fix" the mock to make any test pass. :-) Of course, if you're going to rerun these tests against the real implementation then that is fine. You probably want to design these tests for this reuse in mind? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133313#4133313 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133313

16 years, 10 months

1
0
0 / 0

[Design of OSGi Integration] - Re: Logging and Exception Handling

by alesj

Hmm, I thought I fixed that one. And looking at the FileSystemContext line 255 in the trunk code, there is nothing 'useful' there. I'll run the tests and see what the real cause is. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133312#4133312 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133312

16 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Re: JBAS-5268, AbstractTopLevelClassLoaderDeployer

by adrian＠jboss.org

Should be by the end of next week. I've put Friday as the target date in JIRA for all the RC1, Beta11 releases getting integrated into JBossAS. This should include the war classloader prototype. I don't want to have to rework the RC1 releases if I find a problem later. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133310#4133310 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133310

16 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Re: JBAS-5268, AbstractTopLevelClassLoaderDeployer

by scott.stark＠jboss.org

So I was trying to understand if your doing a JBossCL.2.0.0.Beta11/JBossMC-2.0.0.Beta11 release for the affected projects in the near term so I could start looking at using this. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133306#4133306 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133306

16 years, 10 months

1
0
0 / 0

[Design of JBoss Build System] - Re: Moving jbossas to a maven repo for thirdparty

by scott.stark＠jboss.org

So what I was talking about on the call was just updating the libraries.ent that was being included in the testsuite/build.xml and build/build-distr.xml to include the ../thirdparty/target/ versions: | testsuite/build.xml | <?xml version="1.0" encoding="UTF-8"?> | <!DOCTYPE project [ | <!ENTITY libraries SYSTEM "../thirdparty/target/libraries.ent"> | <!ENTITY testsuite-libraries SYSTEM "../thirdparty/target/testsuite-libraries.ent"> | <!ENTITY modules SYSTEM "../tools/etc/buildmagic/modules.ent"> | ]> | | <project default="main" name="JBoss/Testsuite" | | build/build-distr.xml | <?xml version="1.0" encoding="UTF-8"?> | <!DOCTYPE project [ | <!ENTITY libraries SYSTEM "../thirdparty/target/libraries.ent"> | ]> | | <project name="JBoss/Build"> | If you want to not even affect the existing build files, then have the thirdparty maven package target replace the thirdparty/libraries.ent and testsuite-libraries.ent with updated versions that refer to the thirdparty/target/* jars. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133303#4133303 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133303

16 years, 10 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Update the relevant .classpath files

by adrian＠jboss.org

"ALRubinger" wrote : "adrian(a)jboss.org wrote : It's not a vote. Either make a logical argument or go join some Apache project where you can make these usless comments to your hearts content. :-) | | We get it, Adrian, you're intimidating. | No just don't have time to read drivel :-) anonymous wrote : | I'll spell it out, then. | | Adding .classpath and .project files to the repo might seem like a convenience to users of the Eclipse IDE, but actuality what we're doing here is introducing elements that are unbound to actual changes in the POM, and may be misleading. | | By guaranteeing a build that will function from the command-line only, we add a fail-fast; compilation WILL fail in IDEs. It becomes the responsibility of the developer to add extensions to make it work in their preferred environment. And with the maven commands I've illustrated, it's incredibly simply to do so with Eclipse. We can even bind it to the build lifecycle in an Eclipse profile if we'd like. | | Generated code in a central repo is redundant and easily outdated. And users of IntelliJ (like Ales) shouldn't have to worry about the CP of Eclipse users. | | S, | ALR We'll continue to disagree. Technical * It's called an I(ntegrated)DE for a reason * "Baby sitting" builds and tools is not what I want to do * Remembering and performing recipes of many tool procedures is not productive (it's a good job I know how to program bash, but that's just a hack around the problem :-) * Eclipse is what I use, we can do the same for Intellij (actually I don't use eclipse as much as I could because sometimes it is just too painful) * Checking in the eclipse files in svn makes little difference in practice unless everybody updates them you have to run mvn eclipse:eclipse anyway. It's just you have N updaters running it instead of one committer. Philosophy * Redundancy is only a problem when it leads to error or reduced performance * Redundancy to improve performance and reduce error is a good thing * Claiming that it can lead to error in checking .classpath files because the real problem is in maven/eclipse not being able to understand each other mistates where the problem lies. * When it annoys me enough, I'll fix the real problem, in the meantime it's workarounds and lots of hair pulling :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133299#4133299 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133299

16 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Re: JBAS-5268, AbstractTopLevelClassLoaderDeployer

by adrian＠jboss.org

You can't until I've tested/updated the other stuff in JBossAS. It uses the new ClassLoading/Module spi to create a managed classloader with dependencies for the subdeployment. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133293#4133293 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133293

16 years, 10 months

1
0
0 / 0

[Design of OSGi Integration] - Re: Logging and Exception Handling

by adrian＠jboss.org

The test is acutally wrong since it expects the FileNotFoundException :-) You should also be using: | catch (Throwable t) | { | checkDeepThrowable(FileNotFoundException.class, t); | } | so you get a better error message if the throws the wrong exception. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133292#4133292 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133292

16 years, 10 months

1
0
0 / 0

[Design of OSGi Integration] - Re: Logging and Exception Handling

by adrian＠jboss.org

Looks like a bug in Ales's getChild() to me like I said above | Caused by: java.io.FileNotFoundException: File does not exist: /home/ejort/microcontainer/osgi-int/target/tests-classes/org/jboss/test/bundl | e/helper/simple.jar/mising | at org.jboss.virtual.plugins.context.file.FileSystemContext.createVirtualFileHandler(FileSystemContext.java:255) | at org.jboss.virtual.plugins.context.file.FileSystemContext.createVirtualFileHandler(FileSystemContext.java:192) | at org.jboss.virtual.plugins.context.file.FileHandler.createChildHandler(FileHandler.java:209) | at org.jboss.virtual.plugins.context.AbstractVirtualFileHandler.structuredFindChild(AbstractVirtualFileHandler.java:359) | at org.jboss.virtual.plugins.context.file.FileHandler.getChild(FileHandler.java:217) | at org.jboss.virtual.VirtualFile.getChild(VirtualFile.java:407) | at org.jboss.test.bundle.support.TestVFSDeploymentUnit.getFile(TestVFSDeploymentUnit.java:83) | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133289#4133289 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133289

16 years, 10 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums February 2008