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

[Design of JBoss jBPM] - Re: iCalendar wrapper

by aapthorp

anonymous wrote : Personally, I'd wonder if DTSTART, LOCATION, PERCENT and CLASS can be left out for now. I agree that these may not be immediate requirements, but wonder if there are some missing requirements here...or some not so obvious mappings. For my purposes I used task variables for DTSTART and LOCATION. anonymous wrote : The task variables should be as easily readable as possible, so I'd not go for X- properties. Putting them in the description would also not be my favourite, so that leaves the ATTACH option or leave them out completely (at first). I need to look a bit further at the possibilities of ATTACH, for readonly purposes I formatted them into the description. anonymous wrote : Additionally, I'd include a link somewhere that directly opens the task form page. For me that would be a near-perfect first release. Yes, already done. anonymous wrote : A XUL based ui could be nice, but why not just use the /a webbased page for updating? That's certainly the short term approach, but what I'm thinking about here are the possibilities of providing task specific extensions to PIM type tools for both off-line and on-line useage. Or to put it another way how far does the iCalendar set of RFCs go to provide a standard Human Task protocol? Having just come across WS-HumanTask buried alongside BPEL4People I need to see how close the two compare... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4139852#4139852 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4139852

16 years

1
0
0 / 0

[Design of JBoss Build System] - Maven Version Ranges - Summary

by adrian＠jboss.org

See other threads for details and to make comments: DEPENDENCIES http://www.jboss.com/index.html?module=bb&op=viewtopic&t=132677 The version ranges do actually work as they are supposed, so iof there weren't other problems then I'd suggest we use them. VERSION FORMAT http://www.jboss.com/index.html?module=bb&op=viewtopic&t=132665 To make it work we need to use the Maven version format, i.e. 1.2.3-qualifier-1 We should also use lower case qualifiers to avoid confusion http://www.jboss.com/index.html?module=bb&op=viewtopic&t=132674 RELEASE PLUGIN http://www.jboss.com/index.html?module=bb&op=viewtopic&t=132666 We also need to use 2.0-beta-7 for the release process to work at all, but there's something broken at repository.jboss.org http://www.jboss.com/index.html?module=bb&op=viewtopic&t=132668 GENERATE RELEASE POMS http://www.jboss.com/index.html?module=bb&op=viewtopic&t=132667 I think we should do this anyway SNAPSHOTS http://www.jboss.com/index.html?module=bb&op=viewtopic&t=132669 Snapshots in the local repository break things during the release process, so you have to zap them before starting. But purge-local-repository doesn't work if you use version ranges. Older snapshots also cause problems during development http://www.jboss.com/index.html?module=bb&op=viewtopic&t=132669 why do we keep all snapshots anyway? A method to purge snapshots from snapshots.jboss.org would solve this problem. There's also known bugs related to snapshots (pretty much what I describe above) see the first link. SUMMARY Provided that we have; * reliable mechanisms to get rid of snapshots from both the local repository and snapshots.jboss.org * a change to use Maven's version scheme * figure out the problem at repository.jboss.org with the release plugin then version ranges would be a more deterministic mechanism for managing dependencies than the "nightmare" we have now. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4139850#4139850 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4139850

16 years

1
0
0 / 0

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

by adrian＠jboss.org

Another problem is that you can't use: mvn dependency:purge-local-repository -DreResolve=false to zap your dependencies from the local repository when there are version ranges in the pom. It simply doesn't understand the version ranges. Running it with -Dverbose=true just gives an non-descript "error message" | [INFO] ------------------------------------------------------------------------ | [INFO] Building Project2 | [INFO] task-segment: [dependency:purge-local-repository] (aggregator-style) | [INFO] ------------------------------------------------------------------------ | [INFO] [dependency:purge-local-repository] | [INFO] Skipping: project2. It cannot be resolved. | [INFO] Nothing to do for project: test:project2:jar:1.0.0-SNAPSHOT | [INFO] ------------------------------------------------------------------------ | [INFO] BUILD SUCCESSFUL | [INFO] ------------------------------------------------------------------------ | It doesn't even zap the dependencies that aren't version ranges. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4139848#4139848 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4139848

16 years

1
0
0 / 0

[Design of JBoss Build System] - Maven Version Ranges - Dependencies

by adrian＠jboss.org

The good news is the version ranges do actually work. The problem I described related to JBossAS doesn't exist if you use ranges. i.e. common-core has 1.0.1 and 1.0.2 jboss-aop 1.0.1 uses common-core 1.0.1 microcontainer 1.0.1 uses common-core 1.0.2 jboss-deployers 1.0.1 uses microcontainer 1.0.1 jbossas uses jboss-aop 1.0.1 and jboss-deployers 1.0.1 With only suggestions the older common-core 1.0.1 gets used because jboss-aop's dependency is closer to the root of jbossas. With the constraints i.e. replace 1.0.2 with [1.0.2,) for the microcontainer then jbossas uses 1.0.2 as required. Similarly if jboss-aop specified [1.0.1] then no valid constraint is available to satisfy both aop and the mc Maven fails the build as expected. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4139847#4139847 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4139847

16 years

1
0
0 / 0

[Design of JBoss Build System] - Maven Version Ranges - Case sensitivity

by adrian＠jboss.org

One thing I found is that the qualifier being case sensitive is really confusing ;-) 1.0.0-beta-3 > 1.0.0-Beta-4 :-) 1.0.0-beta-3 > 1.0.0-GA Maybe we should stick to all lower case qualifiers to avoid typos causing problems. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4139844#4139844 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4139844

16 years

1
0
0 / 0

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

by adrian＠jboss.org

"alesj" wrote : "adrian(a)jboss.org" wrote : | | If you can reproduce them I don't have a problem. They're not GA releases | | so its not like we'll have to support them for very long. :-) | What about those maven-metadata.xml* files? | Are they crucial for things to be in-synch? No they just list what is in the repository and which is the current version. If you edit them and don't know how to regenerate the checksums then just delete the check sum file(s). Its the binaries/poms that are important. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4139842#4139842 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4139842

16 years

1
0
0 / 0

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

by alesj

"adrian(a)jboss.org" wrote : | If you can reproduce them I don't have a problem. They're not GA releases | so its not like we'll have to support them for very long. :-) What about those maven-metadata.xml* files? Are they crucial for things to be in-synch? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4139841#4139841 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4139841

16 years

1
0
0 / 0

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

by adrian＠jboss.org

"alesj" wrote : "adrian(a)jboss.org" wrote : | | 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. | What about if I push the one's that are in my local repo? | Since all the right versions are there. If you can reproduce them I don't have a problem. They're not GA releases so its not like we'll have to support them for very long. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4139840#4139840 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4139840

16 years

1
0
0 / 0

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

by alesj

"adrian(a)jboss.org" wrote : | 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. What about if I push the one's that are in my local repo? Since all the right versions are there. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4139839#4139839 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4139839

16 years

1
0
0 / 0

[Design of JBoss Build System] - Re: Move dependency management back into app server svn stru

by ALRubinger

"dimitris(a)jboss.org" wrote : Having the AS pom.xml essentially outside the project. That's much different than "the component-matrix pom is a bad idea". :) ---- Though I don't much care where component-matrix lives, we've got conflicting views on the topic of what constitutes a circular dependency. "adrian(a)jboss.org" wrote : If you depend upon a jbossas sub-project then you are doing it wrong. Circular dependency anyone? :-) I don't agree with the above statement. The Thread at http://www.jboss.com/index.html?module=bb&op=viewtopic&t=132229 explains this more fully. In short, the dependency chain can be "AS Assembly > EJB3 > AS Component" just fine. However, if Adrian's comment is true, then moving the component-matrix POM under jbossas/trunk means we cannot depend on it, which defeats its purpose in the first place. ---- "dimitris(a)jboss.org" wrote : 1) Your mission is to deliver a working EJB3 implementation, not screw up the AS build. We've outgrown the current layout of JBossAS. EJB3, webservices, (messaging?), and any future projects need to take advantage of the same libraries/projects that AS does. JBossAS cannot lay claim to exclusive control of these projects. We need to discuss and come to agreement on the direction in which we're heading by identifying the requisite use cases for both AS and AS Component Consumers. Let's try to give that some attention this week. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4139838#4139838 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4139838

16 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums March 2008