[JBoss JIRA] Created: (JBIDE-8667) improve publishing of component sites using composite metadata so that content doesn't vanish and break downstream jobs
by Nick Boldt (JIRA)
improve publishing of component sites using composite metadata so that content doesn't vanish and break downstream jobs
-----------------------------------------------------------------------------------------------------------------------
Key: JBIDE-8667
URL: https://issues.jboss.org/browse/JBIDE-8667
Project: Tools (JBoss Tools)
Issue Type: Bug
Reporter: Nick Boldt
(2011-04-01 10:11:04) nickboldt: and while I'd love to do:
(2011-04-01 10:11:12) nickboldt: mkdir whatever-new
(2011-04-01 10:11:22) nickboldt: rsync newstuff whatever-new
(2011-04-01 10:11:25) nickboldt: rm -fr whatever
(2011-04-01 10:11:29) nickboldt: mv whatever-new whatever
(2011-04-01 10:11:43) nickboldt: so that the time between "it's there" and "it's there and updated" is less
(2011-04-01 10:11:52) nickboldt: I CANNOT with the current infra we have
(2011-04-01 10:12:03) nickboldt: instead I can do an rsync --delete and push into the same folder on top
(2011-04-01 10:12:16) nickboldt: but that means that the metadata will oft be out of whack w.r.t the site content
(2011-04-01 10:12:17) maxandersen: hmmm
(2011-04-01 10:12:41) nickboldt: if you can think of a way to do a "push then rename" instead of "push into existing and clean out cruft"
(2011-04-01 10:12:51) nickboldt: over sftp via a script (non-interactive) then I'm all ears
(2011-04-01 10:13:26) nickboldt: I can't push a script there and run it, or simply connect over ssh and run a script directly
(2011-04-01 10:13:35) maxandersen: well what I was thinking was to do a push of new site into new dir, push site.xml/compositewhatever pointing to new dir and then rsync delete the existing one..
(2011-04-01 10:14:10) maxandersen: sftp rm should work?
(2011-04-01 10:14:13) nickboldt: MIGHT be able to do sftp delete
(2011-04-01 10:14:39) maxandersen: if you control it with a composite artifact you dont need to rename anything
(2011-04-01 10:14:51) maxandersen: except the content pointer in there which you know "locally"
(2011-04-01 10:15:01) nickboldt: true... so I'd need a tool to do a one line swap in the composite*.xml files
(2011-04-01 10:15:13) nickboldt: remove ref to old site, replace w/ ref to new site
(2011-04-01 10:15:17) nickboldt: and then delete the old one
1. generate composite metadata files on the fly
2. publish that into root dir, all/repo/
3. purge previous build's folder over scripted sftp?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] Created: (JBIDE-8863) Error deploying EAR with a module having a sub-module in its component descriptor.
by Philippe Guinot (JIRA)
Error deploying EAR with a module having a sub-module in its component descriptor.
----------------------------------------------------------------------------------
Key: JBIDE-8863
URL: https://issues.jboss.org/browse/JBIDE-8863
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: core
Affects Versions: 3.2.0.Final
Environment: Tested with Eclipse Indigo Release 20110319-2305 with latest nightly build trunk of JBoss Tools.
Deploying on a JBoss 4.2 server.
Reporter: Philippe Guinot
Assignee: Max Rydahl Andersen
h3.Context:
For some reasons I have to deploy an EAR webapp with (in its libs) a jar containing itself another jar.
h3.Environment:
For this I have a first Java project with the following component descriptor:
{code:xml}
<?xml version="1.0" encoding="UTF-8"?>
<project-modules id="moduleCoreId" project-version="1.5.0">
<wb-module deploy-name="project1">
<wb-resource deploy-path="/" source-path="/src/main/java"/>
</wb-module>
</project-modules>
{code}
Then, the second Java project has the component descriptor:
{code:xml}
<?xml version="1.0" encoding="UTF-8"?>
<project-modules id="moduleCoreId" project-version="1.5.0">
<wb-module deploy-name="project2">
<wb-resource deploy-path="/" source-path="/src/main/java"/>
<dependent-module archiveName="project1.jar" deploy-path="/lib" handle="module:/resource/project1/project1">
<dependency-type>uses</dependency-type>
</dependent-module>
</wb-module>
</project-modules>
{code}
Then, in Eclipse when exporting the *project2* as a *Module Archive*, I obtain a .jar file featuring both classes from *project2* and a *lib* folder with the project1 compiled jar.
Now, in the ear project I have the following lines in the component descriptor:
{code:xml}
<dependent-module archiveName=" project1.jar" deploy-path="/lib" handle="module:/resource/ project1/ project1">
<dependency-type>uses</dependency-type>
</dependent-module>
<dependent-module archiveName=" project2.jar" deploy-path="/lib" handle="module:/resource/ project2/ project2">
<dependency-type>uses</dependency-type>
</dependent-module>
{code}
(The EAR needs the 2 jars as well)
h3.Problem:
Then, when deployed into my *JBoss 4.2 Runtime* server in Eclipse, I got the following error:
{code}Error renaming C:\DEV\jboss\server\default\tmp\jbosstoolsTemp\tmp7021855122707247750.jar to C:\DEV\jboss\server\default\deploy\EAR_Project.ear\lib\project2.jar\lib\project1.jar{code}
After some research, I think an exception is thrown at *org.jboss.ide.eclipse.as.core.server.xpl.PublishCopyUtil.LocalCopyCallback.moveTempFile(File, File)* during the safe rename.
However, when I look to the error message I got the feeling that the publishing process want to copy the tmp jar file into a folder called "*C:\DEV\jboss\server\default\deploy\EAR_Project.ear\lib\project2.jar\lib\*" which can not work because "*C:\DEV\jboss\server\default\deploy\EAR_Project.ear\lib\project2.jar*" is a file.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] Created: (JBIDE-8866) Move all plugins up to baseline
by Rob Stryker (JIRA)
Move all plugins up to baseline
-------------------------------
Key: JBIDE-8866
URL: https://issues.jboss.org/browse/JBIDE-8866
Project: Tools (JBoss Tools)
Issue Type: Task
Components: Build/Releng
Affects Versions: 3.3.0.M2
Reporter: Rob Stryker
Assignee: Nick Boldt
Fix For: 3.3.0.M2
Not really sure who to assign this to, short of making three dozen separate jira issues ;) I have 33 patches, one for each module, which modify all manifest.mf version numbers (in plugins, not in tests) to be brought up to our current baseline.
So assuming our baseline for some specific plugin is 3.6.200, these patches will turn a dependency on this.specific.runtime into this.specific.runtime;bundle-version="3.6.200". If a plugin currently reads this.specific.plugin;bundle-version="3.5.0", it will move it up to this.specific.runtime;bundle-version="3.6.200".
Etc.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months