Menu
▾
▴
jboss-dev-forums
|
From: <ad...@jb...> - 2005-07-26 23:55:00
|
This doesn't work for me. It looks to be problem with the version of ant in tools since plain "ant" works but build.sh does not: adrian@adrian-srv01:~/jboss-4.0/workspace/build> ant -version Apache Ant version 1.6.5 compiled on June 2 2005 adrian@adrian-srv01:~/jboss-4.0/workspace/build> ./build.sh -version Apache Ant version 1.6.2 compiled on July 16 2004 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886699#3886699 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886699 |
|
From: <ad...@jb...> - 2005-07-27 00:03:46
|
Also, I thought we were keeping the thirdparty directory structure the same? I've now got to waste god knows how long revamping the eclipse build to have the new location of all the thirdparty jars. I went through a long argument before about why it was NOT a good idea including the version in the directory structure or the jar name that the local build sees. The version belongs in the manifest and the repository directory structure and it comes originally from the description in the build.xml or component-info.xml View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886700#3886700 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886700 |
|
From: <ad...@jb...> - 2005-07-27 00:06:16
|
This is the error I see: | adrian@adrian-srv01:~/jboss-4.0/workspace/build> ./build.sh -f build-thirdparty.xml | Buildfile: build-thirdparty.xml | | synchronize.main: | [exec] Unknown argument: -cp | [exec] ant [options] [target [target2 [target3] ...]] | [exec] Options: | [exec] -help, -h print this message | [exec] -projecthelp, -p print project help information | [exec] -version print the version information and exit | [exec] -diagnostics print information that might be helpful to | [exec] diagnose or report problems. | etc. | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886701#3886701 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886701 |
|
From: <rl...@jb...> - 2005-07-27 01:52:27
|
Adrian,
Please execute the below command and send me the results. It will create the errorlog.txt file in the build directory. This will eliminate the need for me to ask the standard what os are you using questions.
./build.sh -f build-thirdparty.xml -verbose -logfile errorlog.txt
From your previous posts it looks like you are getting additional arguments added in when ant is launched for the synchronize.targets target.
When I run in verbose mode my output is the following:
| synchronize.main:
| [exec] Current OS is Windows XP
| [exec] Executing 'cmd.exe' with arguments:
| [exec] '/c'
| [exec] 'ant'
| [exec] '-f'
| [exec] 'c:\projects\fresh40backup\jboss-4.0\build\build-thirdparty.xml'
| [exec] 'synchronize.components'
| [exec]
| [exec] The ' characters around the executable and arguments are
| [exec] not part of the command.
I think we will see extra arguments in the above in your error log.
The process is launched in this fashion (found in the tasks.xml file):
Was this checked out to an empty directory? I would like to eliminate the possibility of the ${execant.args} being set in a property file.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886706#3886706
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886706
|
|
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 |
|
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: <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: <ad...@jb...> - 2005-07-27 16:51:08
|
"rl...@jb..." wrote : ...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? Yes, except that now we have more control over the versions, (and we will get even more control as the new build move forwards), something that was a nightmare when it was in a non-versionable module definition in CVSROOT/modules. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886857#3886857 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886857 |
|
From: <sco...@jb...> - 2005-07-27 17:21:48
|
We are never back to the current situation because: 1. Its not an unversioned CVSROOT/modules admin file that defines the makeup of the thirdparty tree. 2. The master build is defining the versions explicitly so this is what controls what goes into a release. This is a versioned file that can easily be monitored and manged for project specific changes. 3. Developers are not updating thirdparty libraries with who knows what version, license, etc. and checking them in. This is done by populating the repository, and strict adherence to population of a valid component info will be required for any content checked in there. All Adrian is saying is that propagation of the version info to local workspace paths just makes life difficult. The local version info is superflous. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886868#3886868 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886868 |
|
From: <rl...@jb...> - 2005-08-03 13:27:22
|
Now that the build for the 4.0 branch has been deployed I am looking at my roadmap. The next item in my queue is to port the thirdparty build to head. Is this in line with everyone's expectations? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888173#3888173 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888173 |
|
From: <sco...@jb...> - 2005-08-03 15:16:45
|
Yes. Send out an email to the dev list so everyone is aware. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888188#3888188 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888188 |
|
From: oommoo <do-...@jb...> - 2005-12-12 00:03:24
|
Where would one get a current such set of ant tasks as would be found in the mentioned, build-thirdparty.xml more, l8r, v View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3912001#3912001 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3912001 |
|
From: <ani...@jb...> - 2005-12-15 21:18:50
|
Should we make a clean build of jboss clean up the thirdparty folder? The reason is that I had a case where tomcat folder in thirdparty was holding onto a version that should have been replaced with a rolled back version. Might be an arbitrary case. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3912989#3912989 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3912989 |
|
From: <rl...@jb...> - 2005-12-15 21:24:57
|
Cruise control always does a clean checkout and build. If you roll back a version there can be issues if the jars in your thirdparty directory are newer than the versions you have rolled back to. A jira issue has been opened for this. You can delete your local thirdparty folder and let it be rebuilt. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3912990#3912990 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3912990 |
|
From: <ani...@jb...> - 2005-12-16 04:49:26
|
"rl...@jb..." wrote : | You can delete your local thirdparty folder and let it be rebuilt. | If I was satisfied with manually cleaning up the thirdparty folder and rebuilding, I would not have raised a question. ;) Maybe the ant built script should be smart enough to do the following: If access to repository.jboss.com exists, then the clean build should clean up the thirdparty folder. If you are building offline, better not clean the thirdparty folder. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3913046#3913046 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3913046 |
|
From: <sco...@jb...> - 2005-12-16 06:17:04
|
A clean should not be required to detect a pickup a new version. the difference in the version should be detected and the thirdparty component replaced. The current get task used for this does not have enough capability last time I looked. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3913054#3913054 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3913054 |
|
From: <sco...@jb...> - 2005-12-16 06:18:23
|
"oommoo" wrote : Where would one get a current such set of ant tasks as would be found in the mentioned, | | build-thirdparty.xml | See the tools/etc/jbossbuild/* content in the workspace. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3913055#3913055 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3913055 |
|
From: <ani...@jb...> - 2005-12-16 07:04:28
|
"sco...@jb..." wrote : A clean should not be required to detect a pickup a new version. the difference in the version should be detected and the thirdparty component replaced. The current get task used for this does not have enough capability last time I looked. Thats the right approach. In the interim, I do suggest a cleanup of the thirdparty folder on a clean build, until the get task is made smart. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3913061#3913061 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3913061 |
|
From: <ani...@jb...> - 2005-12-29 18:24:27
|
| <componentref name="jboss/cache" version="1.2.4_sp1"/> | <componentref name="jboss/remoting" version="snapshot"/> | <componentref name="jboss/serialization" version="snapshot"/> | Both the remoting and the serialization projects work off the snapshot concept. This is not friendly for developers when they want to check if something is failing because of a snapshot. There is no way we can rollback to an earlier version, without contacting Tom/Clebert. Can we mandate all projects to have version numbers please? http://jira.jboss.com/jira/browse/JBWS-547 has a comment from me at the end where I was unsure if the testcase was choking because of something I did to the security layer or the remoting snapshot update. I did not have to contact Telrod to roll back to see if there were issues. :) | User: telrod | Date: 05/12/29 10:10:26 | | Modified: jboss/remoting/snapshot/lib jboss-remoting.jar | Log: | Rolling back to version 1.6 (last known version working). | | Revision Changes Path | 1.12 +2062 -2182repository.jboss.com/jboss/remoting/snapshot/lib/jboss-remoting.jar | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3914783#3914783 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3914783 |
|
From: <rya...@jb...> - 2005-12-30 20:59:27
|
Yes, we should mandate version numbers. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3914966#3914966 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3914966 |
|
From: <ani...@jb...> - 2006-01-01 04:06:10
|
I take back what I said earlier (Adrain would have corrected me - he is on vacation though, plus at the beginning of this forum thread, he does mention about this). If a clean of JBoss build, cleans up the thirdparty folder, then eclipse freaks out unless the cleaning retains the eclipse metadata files for the project in the thirdparty folder. I would have to delete the thirdparty project in eclipse and recreate it AND it will do a time-consuming full build. So an interim solution I suggested (about cleaning up the thirdparty folder during jboss clean) is not perfect for eclipse users (incl. me). The only solution and the right solution is to enhance the gettask of jbossbuild to consider rolled back version of thirdparty libraries and bring them accordingly. Wonder if we have any volunteers to do this task? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3915079#3915079 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3915079 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X