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

[Design the new POJO MicroContainer] - Re: Putting MC artifacts to our maven repo

by adrian＠jboss.org

"alesj" wrote : | The thing is that I've done that, but than later on modified those files. :-( | Don't ask me why. :-) | But now I cannot run that again. Some mvn complain again. | Surprisingly enough. :-) You can't modify the files AFTERwards, the build/artifacts wouldn't be reproducable. If you want to start again, delete the tag from SVN. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4139836#4139836 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4139836

17 years, 9 months

1
0
0 / 0

[Design of POJO Server] - Re: EJB/War deployer ordering problem

by adrian＠jboss.org

"gavin.king(a)jboss.com" wrote : "scott.stark(a)jboss.org" wrote : Why can't use just use the @EJBs on the servlet class as a hint about the ordering requirements? | | There are no @EJB annotations why using Seam. I suspect that longer term we'll want some way of retrieving what Seam does to resolve the ejb so we can properly manage cross deployment dependencies that Seam creates. e.g. a standalone seam war referencing a different ejb deployment will need to know when that ejb deployment gets recycled. The bootstrap (initial deployment) is just a special case of this. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4139835#4139835 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4139835

17 years, 9 months

1
0
0 / 0

[Design of POJO Server] - Re: EJB/War deployer ordering problem

by adrian＠jboss.org

I don't understand what the issue is here? You've always been able to override the order that ejbs/wars get deployed in. This is the "relativeOrder" property on the ContextInfo http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/jboss-deploye... and works the same way as the old suffix ordering in jboss4.x It's just that the WarStructure deployer doesn't set it. Of course this doesn't work (in the same way it didn't work in jboss-4.x) if the war has external dependencies that aren't satisifed immediately. But then that's the problem with using "heuristics" instead of real dependencies. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4139834#4139834 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4139834

17 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Putting MC artifacts to our maven repo

by alesj

What's the easiest way to push these new releases to our Maven2 repo? The instructions here - http://wiki.jboss.org/wiki/Wiki.jsp?page=MavenReleaseProcess Suggest you do this: anonymous wrote : | Perform the release | | Next run the perform step which will checkout the files from the tag, do a build, and deploy the generated artifacts. | | mvn release:perform | | The deployment is done to the local file system (a local checkout of the jboss maven2 repository), so you will need to commit the new files after they are deployed. | | Note that the release process updates your project's pom.xml to change the to the next version. You need to check this updated pom into cvs/SVN. The thing is that I've done that, but than later on modified those files. :-( Don't ask me why. :-) But now I cannot run that again. Some mvn complain again. Is there an easier way than plain hand copying from my local repo to fit our global repo? What about these maven-metadata.xml files: - http://repository.jboss.org/maven2/org/jboss/jboss-mdr/maven-metadata.xml Who modifies those in the first place? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4139833#4139833 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4139833

17 years, 9 months

1
0
0 / 0

[Design of JBoss Build System] - Re: Maven Version ranges - The version format

by adrian＠jboss.org

"alesj" wrote : "adrian(a)jboss.org" wrote : | | However Maven doesn't use that scheme: | | http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+... | | instead it is | | major.minor.micro-qualifier-build | | | | So our | | jboss-5.0.0.Beta4 | | should be under maven | | jboss-5.0.0-Beta-4 | | for the version ranges to work properly. | Can't you hack this? | e.g. first trying how maven wants it, then also try our own | So that the old stuff would still work. How? Something like | <dependency> | <groupId>org.jboss</groupId> | <artifactId>jbossas</artifactId> | <version format="OSGi">5.0.0.Beta4</version> | </dependency> | With some config that tells maven how to parse versions into its format? | <version-format name="OSGi">org.jboss.maven.OSGiVersionParser</version-format> | I'd guess it probably isn't as simple as that (but I haven't looked at the code. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4139831#4139831 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4139831

17 years, 9 months

1
0
0 / 0

[Design of POJO Server] - Re: EJB/War deployer ordering problem

by gavin.king＠jboss.com

This was a (nice) piece of value add that JBoss EJB3 provided, and Seam took advantage of. This was not just "nice", but essential to the usability of Seam. Without it, we can't say that Seam requires no XML. Basically, I'm not happy to say that Seam supports JBoss5 until this feature is back in. So if you want Seam to be in the next release of JBoss5, we need it back in *now*. This is important. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4139830#4139830 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4139830

17 years, 9 months

1
0
0 / 0

[Design of POJO Server] - Re: EJB/War deployer ordering problem

by gavin.king＠jboss.com

"scott.stark(a)jboss.org" wrote : Why can't use just use the @EJBs on the servlet class as a hint about the ordering requirements? There are no @EJB annotations why using Seam. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4139829#4139829 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4139829

17 years, 9 months

1
0
0 / 0

[Design of JBoss Build System] - Maven Version ranges - Snapshots during development

by adrian＠jboss.org

So far I've done minimal testing of the version ranges themselves, but one issue I have found is that once you have a snapshot it will generally screw things up. I guess this is related to the bugs I linked on the other thread. e.g. supposing you have 1.0.0-SNAPSHOT then you release 1.0.0-Beta-2 You would expect somebody with a constraint | [1.0.0-Beta-3,) | to have a failed build, but it will use the older snapshot instead. 1.0.0-SNAPSHOT > 1.0.0-Beta-3 Of course that's probably what you want when you are doing a snapshot after 1.0.0-Beta-3 since you then want the constraint satisifed by the snapshot. What's worse is that somebody with a constraint | [1.0.0-Beta-2,) | will also use the older snapshot. Even worse when you try to do a release it asks you if you want to resolve the snapshot (it thinks that is a valid version if it is in your local repository - the snapshot repository is of course ignored). So you have to zap all the snapshots from your local maven repository before doing releases otherwise you end up with something like: | | FIRST IT ASKS YOU IF YOU WANT TO RESOLVE THE SNAPSHOTS | | [INFO] Checking dependencies and plugins for snapshots ... | There are still some remaining snapshot dependencies.: Do you want to resolve them now? (yes/no) no: : yes | | WHICH ONES | | Dependency type to resolve,: specify the selection number ( 0:All 1:Project Dependencies 2:Plugins 3:Reports 4:Extensions ): (0/1/2/3) 1: : 0 | | THEN IT BARFS ;-) | | Resolve All Snapshots.: [INFO] ------------------------------------------------------------------------ | [ERROR] FATAL ERROR | [INFO] ------------------------------------------------------------------------ | [INFO] null | [INFO] ------------------------------------------------------------------------ | [INFO] Trace | java.lang.NullPointerException | at java.util.regex.Matcher.getTextLength(Matcher.java:1127) | at java.util.regex.Matcher.reset(Matcher.java:284) | at java.util.regex.Matcher.<init>(Matcher.java:205) | at java.util.regex.Pattern.matcher(Pattern.java:879) | at org.apache.maven.shared.release.versions.DefaultVersionInfo.<init>(DefaultVersionInfo.java:122) | at org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.processSnapshot(CheckDependencySnapshotsPhase.java:392) | at org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.resolveSnapshots(CheckDependencySnapshotsPhase.java:339) | at org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.checkProject(CheckDependencySnapshotsPhase.java:227) | at org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.execute(CheckDependencySnapshotsPhase.java:106) | at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:194) | at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:131) | at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:94) | at org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:136) | at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447) | at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) | at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) | at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) | at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) | at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:224) | at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) | at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333) | at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) | at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) | at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) | at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) | at java.lang.reflect.Method.invoke(Method.java:585) | at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) | at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) | at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) | at org.codehaus.classworlds.Launcher.main(Launcher.java:375) | The handling of snapshots is definetly not ready for prime time. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4139828#4139828 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4139828

17 years, 9 months

1
0
0 / 0

[Design of JBoss Build System] - Re: Maven Version ranges - generateReleasePoms

by adrian＠jboss.org

17 years, 9 months

1
0
0 / 0

[Design of JBoss Build System] - Maven Version ranges - Something rotten at repository.jboss.

by adrian＠jboss.org

While doing my version range testing, I can't get it to work over repository.jboss.org When I try to perform my release I get a bizzarre error message for this constraint | <dependency> | <groupId>junit</groupId> | <artifactId>junit</artifactId> | <version>[4.4]</version> | <scope>test</scope> | </dependency> | | [INFO] Executing: mvn deploy --no-plugin-updates -Prelease -P local-properties,jboss.repository -f pom.xml | [INFO] Scanning for projects... | WAGON_VERSION: 1.0-beta-2 | [INFO] ------------------------------------------------------------------------ | [INFO] Building Project2 | [INFO] task-segment: [deploy] | [INFO] ------------------------------------------------------------------------ | [INFO] [resources:resources] | [INFO] Using default encoding to copy filtered resources. | [INFO] ------------------------------------------------------------------------ | [ERROR] BUILD ERROR | [INFO] ------------------------------------------------------------------------ | [INFO] Failed to resolve artifact. | | Couldn't find a version in [3.8.2-brew] to match range [4.4,4.4] | junit:junit:jar:null | | from the specified remote repositories: | central (http://repo1.maven.org/maven2), | repository.jboss.org (http://repository.jboss.org/maven2), | snapshots.jboss.org (file:///home/ejort/temp/snapshots), | repository (file:///home/ejort/temp/maven-repository) | This is despite the fact that I can see in the release-pom.xml that it has actually resolved it to 4.4 | <dependency> | <groupId>junit</groupId> | <artifactId>junit</artifactId> | <version>4.4</version> | <scope>test</scope> | </dependency> | Also, I don't know why it is searching in snapshots at this stage? Anyway, when I just run my tests over repo1.maven.org, I don't see this problem. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4139825#4139825 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4139825

17 years, 9 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums March 2008