[01:00:06] <jbossbot> git [shrinkwrap] push master da78de3.. Andrew Lee Rubinger [SHRINKWRAP-251] Update to reloaded-vdf-bootstrap-minimal which does not depend upon SW, removing the cyclic dependency
[01:00:07] <jbossbot> jira [SHRINKWRAP-251] Remove cyclic dependency [Open, Blocker, Andrew Rubinger] https://issues.jboss.org/browse/SHRINKWRAP-251
[01:00:08] <jbossbot> git [shrinkwrap] push master URL: http://github.com/shrinkwrap/shrinkwrap/compare/70b8a6e...da78de3
[01:07:51] <jbossbot> git [shrinkwrap] push SHRINKWRAP-140 70b8a6e.. Andrew Lee Rubinger [SHRINKWRAP-250] Update version to 1.0.0-alpha-12-SNAPSHOT
[01:07:52] <jbossbot> jira [SHRINKWRAP-250] Set next release in $version [Open, Major, Andrew Rubinger] https://issues.jboss.org/browse/SHRINKWRAP-250
[01:07:52] <jbossbot> git [shrinkwrap] push SHRINKWRAP-140 da78de3.. Andrew Lee Rubinger [SHRINKWRAP-251] Update to reloaded-vdf-bootstrap-minimal which does not depend upon SW, removing the cyclic dependency
[01:07:53] <jbossbot> jira [SHRINKWRAP-251] Remove cyclic dependency [Resolved, Blocker, Andrew Rubinger] https://issues.jboss.org/browse/SHRINKWRAP-251
[01:07:53] <jbossbot> git [shrinkwrap] push SHRINKWRAP-140 55b3324.. Andrew Lee Rubinger Merge branch 'master' into SHRINKWRAP-140
[01:07:54] <jbossbot> jira [SHRINKWRAP-140] Support loading artifacts from a Maven repository [Open, Major, Karel Piwko] https://issues.jboss.org/browse/SHRINKWRAP-140
[01:07:54] <jbossbot> git [shrinkwrap] push SHRINKWRAP-140 40a9fab.. Andrew Lee Rubinger [SHRINKWRAP-140][SHRINKWRAP-250] Set next release in extension-dependencies
[01:07:54] <jbossbot> git [shrinkwrap] push SHRINKWRAP-140 URL: http://github.com/shrinkwrap/shrinkwrap/compare/bd3c57c...40a9fab
[01:09:18] *** ALR has quit IRC
[01:14:12] *** aslak has quit IRC
[01:20:54] *** rruss has quit IRC
[01:49:05] *** ldimaggi_ has joined #jbosstesting
[02:45:47] *** bgeorges has joined #jbosstesting
[05:21:04] *** jdlee has quit IRC
[06:24:22] *** bobmcw_ is now known as bobmcw
[06:24:23] *** bobmcw has joined #jbosstesting
[06:29:14] *** ldimaggi_ has quit IRC
[07:05:15] *** yahya_h has joined #jbosstesting
[07:18:23] *** oskutka has joined #jbosstesting
[07:55:15] *** awiedenb has quit IRC
[08:03:35] *** Jaikiran has joined #jbosstesting
[08:17:20] *** theute has joined #jbosstesting
[08:28:57] *** jdewinne has joined #jbosstesting
[08:38:33] *** aslak has joined #jbosstesting
[08:38:33] *** aslak has quit IRC
[08:38:33] *** aslak has joined #jbosstesting
[08:40:07] *** rkellerm has joined #jbosstesting
[08:40:35] <rkellerm> Hello Aslak,
[08:41:08] <rkellerm> Ii have a problem I can't solve by myself.
[08:41:23] <rkellerm> "Failed to deploy test.ear"
[08:41:41] <rkellerm> Caused by: java.lang.RuntimeException: org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
[08:42:03] <rkellerm> DEPLOYMENTS MISSING DEPENDENCIES:
[08:42:04] <rkellerm>   Deployment "jboss.j2ee:ear=test.ear,jar=useradminfassade.jar,name=AddressDAOBean,service=EJB3" is missing the following dependencies:
[08:42:04] <rkellerm>     Dependency "<UNKNOWN jboss.j2ee:ear=test.ear,jar=useradminfassade.jar,name=AddressDAOBean,service=EJB3>" (should be in state "Described", but is actually in state "** UNRESOLVED Demands 'persistence.unit:unitName=test.ear/useradminfassade.jar#tmsguide' **")
[08:42:24] <aslak> rkellerm, can you pastebin the whole output?
[08:42:43] <rkellerm> What means pastebin?
[08:42:51] <rkellerm> paste it here?
[08:43:00] *** jdewinne has left #jbosstesting
[08:44:40] <rkellerm> Seems to much to paste it to the dialog.
[08:46:55] <aslak> rkellerm, pastebin.com
[08:49:32] *** lfryc has joined #jbosstesting
[08:49:54] <rkellerm> OK, its here: http://pastebin.com/download.php?i=F1EEy6in
[08:51:30] <aslak> "persistence.unit:unitName=test.ear/useradminfassade.jar#tmsguide" is in error due to the following reason(s): java.lang.ArrayStoreException: sun.reflect.annotation.TypeNotPresentExceptionProxy
[08:52:27] <rkellerm> What to do to solve it?
[08:53:32] <aslak> http://community.jboss.org/message/555566
[09:01:21] <rkellerm> I still dont get it! useradminfassade.jar is my jar made by shrinkwrap, tmsguide is the persistance unit name in :   	<persistence-unit name="tmsguide">
[09:01:21] <rkellerm> 		<jta-data-source>java:/iml-tmsDatasource-Test</jta-data-source>
[09:01:21] <rkellerm>
[09:02:47] <aslak> rkellerm, are you deploying some APIs? e.g. JPA?
[09:03:09] <rkellerm> "iml-tmsDatasource-Test-ds.xml" is in the directory  D:\DEV320\jboss\jboss\server\default\deploy
[09:03:49] *** aslak has quit IRC
[09:04:45] *** aslak has joined #jbosstesting
[09:05:07] <rkellerm> Don't understand.
[09:05:29] <aslak> i do agree, it's a bit of a strange error for a datasource definition
[09:06:44] <aslak> hmm, maybe the datasource is in error, because some of the <class>es it tries to load from your deployment is causing it..
[09:06:55] <rkellerm> It happened just after we achieved a build and test success, then we tried to redo all changes but nothing helped
[09:07:49] <aslak> rkellerm, your using jpa?
[09:07:59] <rkellerm> yes
[09:07:59] *** aslak has quit IRC
[09:08:45] *** aslak has joined #jbosstesting
[09:08:48] <rkellerm> yes
[09:08:59] <aslak> bean validation ?
[09:09:14] <rkellerm> no , we still use jboss 5.1
[09:09:33] <aslak> hmm, any jpa annotations that take custom classes... thinking thinking
[09:10:28] <aslak> rkellerm, you use e.g. @OneToMany(targetEntity=SomeClass.class)
[09:11:01] <aslak> or @OneToOne(targetEntity), or @ManyToOne(targetEntity)
[09:12:07] <aslak> or @IdClass
[09:12:10] <rkellerm> yes, in Entity User.java we use it: 31: @OneToMany(mappedBy="user")
[09:12:27] <aslak> rkellerm, yea, but specificly the targetEntity
[09:12:51] <aslak> we're looking for Annotations that refere to Classes (types) that might not exist
[09:13:07] *** GTobi has joined #jbosstesting
[09:13:24] <rkellerm> no
[09:14:11] <rkellerm> i did a seyrch for "targetEntity" with no results
[09:15:19] <aslak> *sigh* if only the exception could have told us what it can't find
[09:18:27] *** yahya_h has quit IRC
[09:21:30] <aslak> rkellerm, hmm, you can't see the stack trace of the TypeNotPresentE... some where? e.g. in server.log ?
[09:22:01] <Jaikiran> just a fyi - https://issues.jboss.org/browse/JBREFLECT-137 introduces a better error message
[09:22:03] <jbossbot> jira [JBREFLECT-137] java.lang.ArrayStoreException: sun.reflect.annotation.TypeNotPresentExceptionProxy [Closed, Major, Kabir Khan] https://issues.jboss.org/browse/JBREFLECT-137
[09:22:47] <aslak> Jaikiran, great! progress :)
[09:22:55] <Jaikiran> :)
[09:23:20] <aslak> JBREFLECT backward competable woth as 5 ?
[09:23:35] <aslak> compatible with :)
[09:23:52] <Jaikiran> not quite sure. there have been some changes in that area
[09:24:01] <Jaikiran> i think AS5 was on 2.0.x and AS6 is on 2.2.x
[09:24:15] <Jaikiran> kabir/ales will know better
[09:24:40] <aslak> :)
[09:33:44] *** mgoldmann has joined #jbosstesting
[09:54:43] *** jeand has joined #jbosstesting
[10:04:28] *** michaelschuetz has joined #jbosstesting
[10:06:09] *** aslak has quit IRC
[10:06:46] *** aslak has joined #jbosstesting
[10:11:38] *** wolfc has joined #jbosstesting
[10:52:32] *** jharting has joined #jbosstesting
[11:36:18] *** pmuir has joined #jbosstesting
[11:58:36] *** michaelschuetz has quit IRC
[11:59:22] *** michaelschuetz has joined #jbosstesting
[12:25:53] *** Jaikiran has quit IRC
[12:33:31] *** pmuir has quit IRC
[12:50:15] *** michaelschuetz has quit IRC
[12:51:01] *** michaelschuetz has joined #jbosstesting
[13:00:19] *** kpiwko has joined #jbosstesting
[13:03:54] *** pmuir has joined #jbosstesting
[13:03:54] *** pmuir has quit IRC
[13:03:54] *** pmuir has joined #jbosstesting
[13:19:04] <kpiwko> aslak: hi
[13:25:28] <aslak> kpiwko, heya
[13:27:10] <kpiwko> aslak: I just did a quick research of Arquillian code...trying to figure out how explode an archive instead of deploying it...am I correct if I say that this need a change of the container API?
[13:28:13] <kpiwko> if we supported exploded mode, we can easily use arquillian to test development mode with GWT ;)
[13:33:21] <aslak> kpiwko, hmm, yea, this came up on Devoxx as well
[13:34:14] <aslak> kpiwko, it is one thing deploying it exploded, but for that to have any effect you need to keep the deployment alive
[13:35:21] <kpiwko> aslak, this holds even for deployment on remote container in AS_CLIENT mode?
[13:35:43] *** johnament has joined #jbosstesting
[13:36:03] <aslak> we were discussion what we could do with a Eclipse Arquillian WTP server adaptor..  we could then deploy exploded, or not. but keep the deployment active, and do partial redeploy as we get callbacks from eclipse about change etc
[13:37:11] <kpiwko> aslak, I don't thing intergrating eclipse part is the right direction
[13:37:17] <kpiwko> aslak, maybe for tests in IDE
[13:37:26] <kpiwko> aslak, but definitely not for automatization
[13:37:57] <aslak> kpiwko, maybe i missunderstood your point. why do you want to deply it exploded?
[13:38:18] <kpiwko> aslak, but if we supported an API for a (partial) redeploy, we can at least update part of the code on server programatically
[13:39:06] *** ldimaggi_ has joined #jbosstesting
[13:39:55] <aslak> kpiwko, when would we do a partial redeploy
[13:40:40] <johnament> i think this is the first i'm in this room with an active conversation O_O
[13:41:03] <kpiwko> aslak, let's imagine I would like to test following:
[13:41:03] <kpiwko> 1/ I have a GWT class
[13:41:03] <kpiwko> 2/ I explode it on the server
[13:41:03] <kpiwko> 3/ check something with selenium in browser with GWT plugin enabled
[13:41:03] <kpiwko> 4/ update the class
[13:41:04] <kpiwko> 5/ force a partial redeploy
[13:41:04] <kpiwko> 6/ check the page changed
[13:41:35] <aslak> kpiwko, sure, but do you force a partial redeploy in your test ?
[13:42:02] <aslak> if so, why are you testing partial redeployment =?
[13:42:32] <kpiwko> to check GWT developer mode plugin works
[13:43:26] <aslak> kpiwko, is this a real usecase?
[13:43:34] <kpiwko> aslak, yeah
[13:44:16] <kpiwko> aslak, basically the most of it is handled by gwt-maven-plugin
[13:45:29] <aslak> kpiwko, do you develop the gwt plugin?
[13:45:51] <kpiwko> aslak, but if I had a possibility to update deployment during arquillian lifecycle, it would be a huge plus for this usecase
[13:46:11] <kpiwko> aslak, no, I'm just verifying it works against our ASes
[13:46:35] <kpiwko> aslak, I'm not even sure the plugin was OSSed
[13:46:53] <kpiwko> because GWT-Eclipse integration was not
[13:47:02] <aslak> gwt, right.. sorry when you said gwt developmenbt mode i was thinking gae dev mode
[13:47:43] <kpiwko> well, current gwt-maven-plugin supports gae
[13:48:06] <aslak> johnament, heya :)
[13:55:41] <aslak> kpiwko, i think the easiest is to add a couple of config options to the container confi for e.g the jboss containers
[13:56:11] <aslak> deployExploded=true|false, explodedDeploymentPath=target/something
[13:57:38] <aslak> then depending on isDeployExploded, use ZipExporter like we do today, or ExplodedExporter(to the given path pluss set copyContent=false on deploymentMnagaer.deploy(....., copyContent))
[13:58:42] <kpiwko> aslak, I was rather thinking of @Deployment(style=EXPLODED), so it would be archive not container dependent
[13:59:07] <aslak> then you define the deployment as you normally would, it gets exploded on the file system under a known path, and deployed to the server without copying the content. now you can manipulate the deployment as you see fit
[13:59:49] <aslak> kpiwko, i know you were, but it depends on the container if it is supported or not
[14:00:30] <kpiwko> aslak, good point
[14:09:32] *** johnament has quit IRC
[14:18:22] *** Jaikiran has joined #jbosstesting
[14:22:44] *** maeste has joined #jbosstesting
[14:34:39] *** GTobi has quit IRC
[14:47:06] *** lfryc has quit IRC
[14:59:30] *** michaelschuetz has quit IRC
[15:00:17] *** michaelschuetz has joined #jbosstesting
[15:08:56] *** lfryc has joined #jbosstesting
[15:14:22] *** rruss has joined #jbosstesting
[15:15:44] *** jdewinne has joined #jbosstesting
[15:32:10] *** jdewinne has quit IRC
[15:32:11] *** kpiwko has quit IRC
[15:36:43] *** kpiwko has joined #jbosstesting
[15:49:28] *** lightguard_jp has joined #jbosstesting
[15:50:09] *** jharting has quit IRC
[15:53:14] *** ALR has joined #jbosstesting
[16:05:11] *** jdlee has joined #jbosstesting
[16:06:31] *** aslak has quit IRC
[16:07:27] *** aslak has joined #jbosstesting
[16:08:06] *** davidbos has joined #jbosstesting
[16:10:30] *** bobmcw has quit IRC
[16:14:05] *** bobmcw has joined #jbosstesting
[16:44:23] *** aslak has joined #jbosstesting
[16:55:15] *** jharting has joined #jbosstesting
[16:56:22] <ALR> kpiwko: Ping.
[16:57:42] <kpiwko> ALR: pong
[16:58:04] <ALR> kpiwko: Working on splitting the ext-dep stuff into an API
[16:58:19] <ALR> kpiwko: What I want to do is abstract out Aether.
[16:58:44] <ALR> kpiwko: For instance, stuff like this has to get encapsulated:
[16:58:44] <ALR> public interface DependencyFilter<T extends DependencyBuilder<T>> extends org.sonatype.aether.graph.DependencyFilter
[16:59:07] <ALR> kpiwko: And that begs the question:
[16:59:14] <ALR> Do I abstract out Maven grammars too?
[16:59:34] <ALR> Does this become a generic resolution mechanism which knows how to resolve String coordinates?
[16:59:44] <ALR> Or we make the API specific to Maven resolvers?
[16:59:56] <ALR> aslak: ^ You may also wanna join in this discussion.
[17:01:00] <kpiwko> ALR: DependencyFilter might not be defined using extends, it might have a delegate method
[17:01:49] <ALR> There's some other API leaks.
[17:01:52] <kpiwko> ALR: basically DependencyFilter is Maven based thing used before/after resolution on the result tree...
[17:01:57] <kpiwko> ALR: go on
[17:01:59] <ALR> Dependencies imports MavenDependencies for example.
[17:02:49] <ALR> That might be it for the API leaks.
[17:02:51] <kpiwko> ALR: yeah, this should rather  use SecurityActions.newInstance(classname)
[17:02:53] <ALR> Those 2.
[17:03:09] <ALR> kpiwko: Well, even then it's hardcoding a specific impl.
[17:03:15] <ALR> Unless we make that somehow configurable.
[17:03:30] <kpiwko> ALR: any other idea how to choose default implementation?
[17:03:56] <ALR> (ShrinkWrap API is hardcoded to ShrinkWrap impl BTW, an example of how this is sometimes acceptable)
[17:04:13] <ALR> kpiwko: Depends.  Do we intend to use this API for many impls?
[17:04:23] <ALR> Or is the API there just to shield the user from internals?
[17:04:36] <ALR> ShrinkWrap API is there to shield.  Not plug in other backends.
[17:04:42] <ALR> As an example.
[17:04:46] <kpiwko> ALR: guess not...rather the second variant is correct
[17:05:05] <ALR> OK, in that case this module becomes defined as Maven-specific.
[17:05:25] <ALR> So "extension-dependencies" is really "extension-maven-dep" or something similar.
[17:05:29] <kpiwko> ALR: I'm not aware of any other repository system developers would use ATM
[17:05:51] <ALR> kpiwko: If there were, we could make APIs for those too...
[17:06:08] <ALR> DependencyBuilder
[17:06:11] <kpiwko> ALR: the api/impl packages were created with respect to have this possibility simple to use they later on
[17:06:12] <ALR> ...is all Maven grammars.
[17:06:23] <kpiwko> ALR: that's correct
[17:06:30] <ALR> So I think we should define the scope of this module to be Maven resolution.
[17:06:39] <ALR> Allowing Maven grammars in the API.
[17:06:44] <ALR> But shielding out all impl stuff.
[17:06:57] <ALR> Including org.apache.maven and Aether.
[17:07:33] <kpiwko> ALR: can't really resist makes sense at the moment
[17:07:45] <ALR> kpiwko: OK, I'm on it.
[17:07:48] *** pmuir has quit IRC
[17:08:00] <ALR> kpiwko: Unless you wanna see this through.
[17:09:30] <kpiwko> ALR: I think that making DependencyBuilder more general would make it less usable for users
[17:10:02] <kpiwko> and maybe even artifact/exclusion concept cannot be generalized enough
[17:10:31] <ALR> kpiwko: Definitely.  DependencyBuilder is nice.
[17:10:44] <kpiwko> ALR: so if I got it right, that would require DependencyBuilder be almost a marker interface with resolve() method only
[17:11:08] <ALR> kpiwko: You mean if Maven stuff weren't in there?
[17:11:15] <ALR> Yeah, it'd be resolve(String)
[17:11:15] <kpiwko> ALR: artifact(), scope(), etc. would have to switch to MavenDependencyBuilder
[17:11:31] <kpiwko> to switch -> to move
[17:12:13] <kpiwko> ALR: yes, I meant a DependencyBuilder without Maven stuff
[17:12:39] <aslak> there is a somewhat seperation there today isn't there?  between Dependecies and MavenDependencies, where MavenDependencies expose some 'maven' only features?
[17:12:48] * ALR thinking on the benefit of making a general resolver API, a Maven resolver API, and a Maven impl
[17:13:18] <kpiwko> aslak, right MavenDependencies additionally exposes POM, settings.xml etc
[17:13:52] <kpiwko> aslak, but ALR's idea is that even artifact, scope, exclusion are Maven based features
[17:14:14] <kpiwko> e.g. there's no artifact concept if I use a directory as a repository
[17:14:14] <aslak> so we could have a GradleDependencies that would interact with gradle specific build files etc
[17:14:18] *** michaelschuetz has quit IRC
[17:14:29] <kpiwko> aslak, yes, we could
[17:14:33] <ALR> Exactly.
[17:14:44] <ALR> Gradle/Ivy
[17:14:50] <kpiwko> aslak, but only because Gradle and Maven are interoperable
[17:14:50] <aslak> even tho the same repository backend/api, they differ in configuration
[17:15:03] *** michaelschuetz has joined #jbosstesting
[17:15:12] <ALR> Let's do this:
[17:15:16] <ALR> Resolver API
[17:15:24] <ALR> Maven Resolver API extends Resolver API
[17:15:29] <ALR> Maven Resolver Impl
[17:15:46] <ALR> Resolver API resolves String coordinates
[17:15:54] <aslak> ALR, pull the Resolver API into SW API or as a extension?
[17:16:09] <ALR> aslak: It'd have to be an extension.
[17:16:24] <ALR> aslak: Because impl-base wouldn't supply an implementation of it.
[17:16:27] <kpiwko> ALR: resolver is the same as Dependencies ATM or its a abstraction of DependencyBuilder?
[17:16:39] <aslak> mm
[17:17:09] <ALR> kpiwko: It's mostly DependencyBuilder { resolve(String); }
[17:17:18] <kpiwko> ALR: ok
[17:18:10] <kpiwko> ALR, aslak: guys I'm sorry but I'm having an appointment at 6...can we continue this discussion in 2 hours?
[17:18:36] <ALR> kpiwko: If there's more to comb through :)
[17:18:45] <ALR> kpiwko: I'll start moving crap around
[17:19:05] <aslak> this could in theory be a completely different project, nothing that ties it to Shrinkwrap (besides Collection<Archive<?>> which is basically a overhead of import as zip, instead of Collection<File>))
[17:19:17] <ALR> kpiwko: Enjoy the appt.
[17:19:25] <ALR> aslak: Decent point.
[17:19:38] <kpiwko> ALR: if that's all you wanted to ask, find...nevertheless I'll be there if anything arises
[17:19:53] <kpiwko> find -> fine
[17:20:00] *** kpiwko has quit IRC
[17:32:58] <aslak> ALR, fyi.. scala and arq in action, http://pastebin.com/rQ4UrRYe
[17:33:13] <aslak> and sw :)
[17:33:16] <ALR> So cool
[17:33:34] <ALR> aslak: We need to look at other non-Java conferences.
[17:33:40] <ALR> Tosi is right.
[17:33:46] <ALR> ARQ is outgrowing EE.
[17:33:50] <ALR> Same for SW.
[17:33:59] <aslak> that was always the intent.. :)
[17:34:08] <ALR> Def.
[17:34:10] <aslak> to outgrow that is
[17:34:17] <ALR> But we haven't positioned it as such yet
[17:34:55] <aslak> no, we needed one ittle goal, even tho it's designed for more.. hehe
[17:35:00] <aslak> little
[17:35:53] <aslak> when 1.0 is out, i'll start looking at the android + server in a multi container setup..
[17:36:58] <aslak> deploy a client to a 'phone' and deploy the backend to the server, and test incontianer phone/server.. could be really powerful
[17:38:09] <ALR> Wowzah
[17:38:20] <ALR> Yeah, I don't know what Android does for testing now
[17:38:35] <aslak> they have their own brew junit v with in-phone support
[17:39:08] <aslak> not sure how the execution works
[17:39:30] *** oskutka has quit IRC
[17:46:02] *** lfryc has quit IRC
[17:48:22] *** pmuir has joined #jbosstesting
[18:07:55] *** michaelschuetz has quit IRC
[18:08:42] *** michaelschuetz has joined #jbosstesting
[18:10:45] *** davidbos has quit IRC
[18:17:05] <aslak> ALR, is reloaded still active?
[18:17:20] <ALR> aslak: Define "active" :)
[18:17:22] <ALR> Used, yes.
[18:17:28] <ALR> I released a new version yesterday
[18:17:32] <ALR> But it's based on MC
[18:17:52] <aslak> will it be updated to msc, or will it die ?
[18:18:22] <aslak> will it out live as 6 i guess i'm asking
[18:19:10] <ALR> aslak: MSC should have something else.
[18:19:21] <ALR> The Reloaded API is bound to the old Bootstrap and MC APIs too.
[18:19:34] <ALR> aslak: But there should be some functional replacement.
[18:20:03] <aslak> basically a stripped down as profile for 7 ?
[18:20:40] <ALR> aslak: Basically whatever is needed to boot MSC and whatever the deployment mechanism is.
[18:20:48] <aslak> right
[18:21:05] <ALR> I bet that should come sooner than later.
[18:21:12] <ALR> I should ping those guys.
[18:21:17] <ALR> And work on some setup
[18:21:30] <aslak> mc is dicontinnue right?
[18:21:35] <ALR> Yeah.
[18:23:22] *** pmuir has quit IRC
[18:23:28] <ALR> aslak: I got tapped to do http://www.devnexus.com/s/index
[18:24:52] <aslak> ALR, trapped? :)
[18:25:13] <ALR> Hah, no.
[18:25:16] <ALR> I like travel.
[18:25:26] <ALR> Especially to the South in March.
[18:25:40] <aslak> warmer
[18:26:07] <aslak> ALR, accepted or put in paper?
[18:28:38] <ALR> aslak: Backdoor.
[18:28:49] <aslak> ALR, cool
[18:32:05] *** michaelschuetz has quit IRC
[18:34:33] *** maeste has quit IRC
[18:40:10] *** Jaikiran has quit IRC
[18:49:54] *** maeste has joined #jbosstesting
[19:14:29] *** kpiwko has joined #jbosstesting
[19:18:21] <kpiwko> ALR, aslak: hi again :)...have you guys revealed something interesting about SW-140 I'd like to know?
[19:18:35] <ALR> kpiwko: Nope, I'm just picking at it.
[19:18:55] <ALR> kpiwko: Can you describe the motivtion behind ArtifactBuilder as an inner interface of DependencyBuilder?
[19:20:05] <kpiwko> ALR: sure...AritfactBuilder requires an artifact to set properties on
[19:20:25] <kpiwko> this way API ensures user must call artifact before scope
[19:20:49] <kpiwko> No reason to be -> inner <- interface though
[19:21:06] <kpiwko> I guess it developed in time in that
[19:22:00] <ALR> OKee.
[19:22:06] <ALR> So might be extracted.
[19:22:13] <ALR> But you need an existing artifact.
[19:22:29] <kpiwko> maybe as an inner inteface is more hidden...so user is not in temptation to create its instance directly
[19:22:43] <kpiwko> let me see if I can figure out anything else
[19:22:53] <ALR> kpiwko: Nope, that's all fine.
[19:23:09] <ALR> Just dissecting the intended usage
[19:23:25] <ALR> The real user view is MavenDependencies
[19:24:29] <kpiwko> now I see there are two inner ifaces
[19:24:41] <kpiwko> ALR: ArtifactsBuilder as well
[19:24:50] <ALR> Mhmm
[19:25:09] <ALR> Which is a marker
[19:25:18] <kpiwko> ALR this is a bit more important...it allows to have exclusion(), scope() methods behave differently in implementation
[19:26:16] <kpiwko> ALR: so if user calls artifacts(), he gets ArtifactsBuilder, if he calls artifact() he gets ArtifactBuilder...both have same API, but underlying implementation behave differently
[19:27:04] <ALR> In Dependencies, I see.
[19:27:12] <kpiwko> basically for ArtifactsBuilder all methods influence all artifacts defined by artifacts() call
[19:27:21] <kpiwko> which is important in chaining
[19:28:26] <kpiwko> otherwise, you'll set scope() for the last artifact only, which is not what you intended to go if you called artifacts(1,2) before
[19:28:34] <kpiwko> ALR: ^ for instance
[19:28:45] <kpiwko> intended to do
[19:29:07] <ALR> kpiwko: aslak brings up a good point.
[19:29:29] <ALR> kpiwko: The only integration bit w/ ShrinkWrap is "Archive<?> resolve()"
[19:29:35] <kpiwko> ALR: you mean about making it completely standalone
[19:29:35] <kpiwko> ?
[19:30:15] <kpiwko> ALR, aslak: yeath...Archive<?> support and Shrinkwrap.create() calls in tests
[19:30:22] <kpiwko> both can be removed
[19:30:34] * aslak is making dinner.. :)
[19:30:55] <ALR> kpiwko: Also I don't see a method to resolve a singular artifact coordinate
[19:31:20] <ALR> I think the most common case is to know the coordinates, then request the single Archive
[19:31:24] *** michaelschuetz has joined #jbosstesting
[19:31:45] <kpiwko> ALR: ArtifactBuilder<T> artifact(String coordinates) throws DependencyException;
[19:31:51] <kpiwko> in public interface DependencyBuilder<T extends DependencyBuilder<T>>
[19:32:36] <kpiwko> ALR: or you mean call artifact() + resolve() within a single call?
[19:32:58] <ALR> kpiwko: That returns a builder.  The endpoint is when you call Archive<?>[] resolve()
[19:33:32] <kpiwko> ALR: right or File[] resolveAsFiles()
[19:34:10] <ALR> Yep.  I'm looking for just a single artifact.
[19:34:21] <kpiwko> ALR: in my POV method you asked for is not necessary
[19:34:37] <ALR> kpiwko: It's a usability thing.
[19:34:42] <kpiwko> Dependencies.artifact(abc).resolve() is not such a big overhead for me
[19:34:57] <kpiwko> because in real world you might to load pom file as well
[19:35:00] <ALR> With an array the user has to validate the size of the array to be 1..
[19:35:24] <ALR> For deployment for example, you want your JAR only.
[19:35:28] <ALR> Not a search of all deps.
[19:35:32] <ALR> Just the one coordinate
[19:35:55] <kpiwko> well, you can surely define an Archive<?> artifactResolve() method which chains internally
[19:36:57] <ALR> Yup.
[19:37:02] <kpiwko> I guess to be sure it returns one artifact only, it would say
[19:37:02] <kpiwko> Dependencies.artifact(coords).resolve(new StrictFilter());
[19:37:20] <ALR> Some sugar for the users.
[19:37:21] <ALR> :)
[19:37:33] <ALR> Oh, I've kinda renamed this
[19:37:37] <ALR> To "Resolvers"
[19:37:51] <ALR> Which I can't say I love either.
[19:38:07] <kpiwko> ALR: possible...but I'm still using old names in my head...give me some time :)
[19:38:18] <ALR> kpiwko: Which do you prefer?
[19:39:02] <kpiwko> let me see if I can find my old disscussion with aslak about this
[19:39:07] <ALR> kpiwko: http://twitter.com/#!/ALRubinger/status/25259511140843520
[19:39:41] <kpiwko> sorry, I'm not using twitter
[19:39:54] <kpiwko> or I've forgotten my credentials
[19:39:59] <ALR> Just to let ya know :)  We'll ask the masses.
[19:40:06] <kpiwko> :)
[19:41:05] <ALR> kpiwko: Also I'm tempted to cut the 1.0.0-alpha-12 release without SW-140
[19:41:18] <ALR> kpiwko: As it can be done now.  Soon as this gets worked out we'll push another release.
[19:42:29] *** michaelschuetz has quit IRC
[19:42:48] <kpiwko> ALR: do you need a release without SW-140 so soon?
[19:44:28] <kpiwko> ALR: according to discussion with aslak and pete, names suggested were ArtifactResolver, AetherResolver, DependencyResolver, MavenResolver, Dependencies ;)
[19:44:52] <ALR> kpiwko: The sooner it gets out, the more time the API has to bake before we lock it.
[19:45:18] <kpiwko> ALR: this alpha-13 will be available in January as well?
[19:45:39] <ALR> kpiwko: It'd be out whenever we're happy with this.
[19:45:44] <ALR> Tomorrow, the weekend, whenever.
[19:46:01] <ALR> kpiwko: I have now:
[19:46:02] <ALR> org.jboss.shrinkwrap.resolver:shrinkwrap-resolver-api
[19:46:08] <ALR> org.jboss.shrinkwrap.resolver:shrinkwrap-resolver-api-maven
[19:46:17] <ALR> org.jboss.shrinkwrap.resolver:shrinkwrap-resolver-impl-maven
[19:46:22] <kpiwko> ALR: I see...to be honest, I would like to it out asap
[19:46:48] <kpiwko> because I'd like to rely on it in other projects
[19:47:09] <ALR> You have it backwards.
[19:47:17] <ALR> You want SW-140.
[19:47:26] <ALR> Right now SW-140 is holding back alpha-12
[19:47:50] <ALR> Releasing alpha-12 doesn't slow down a fix for SW-140.  That gets done when we finish it. :)
[19:48:05] <ALR> (Except for maybe 30 minutes of my time to actually carry out the release)
[19:48:43] <kpiwko> ALR: that's right...but between alpha-11 and alpha-12 has been a huge time period, so I'm a bit nervous not seeing SW-140 in alpha-12 ;)
[19:49:23] <ALR> kpiwko: I was assigned in the interim.
[19:49:59] <ALR> Don't be scared baby.
[19:50:12] <ALR> SW-140 is getting done/released soon.
[19:50:44] <ALR> (And that's "baby" like in "Swingers".  Not like calling you a baby.)
[19:51:41] <kpiwko> ALR: Maybe another remark...ShrinkWrap's API changes between alpha's as well
[19:52:11] <ALR> kpiwko: Yes.
[19:52:20] <kpiwko> ALR: but if you want to distribute alpha-12 changes asap, not to hold them by SW-140, I can understand it clearly
[19:52:21] <ALR> And in alpha-12 there are a LOT
[19:52:37] <ALR> I'll plug with this for the time being.
[19:52:48] <ALR> If by tonight it's not close to releasable we'll just bump it.
[19:52:58] <ALR> How's that for agile?
[19:53:27] <kpiwko> ALR: very agile ;)
[19:54:26] <kpiwko> ALR: I guess I can follow your changes in your ALRubinger/SW-140 branch, right?
[19:54:44] <ALR> kpiwko: We'll sync together in upstream/SW-140
[19:54:57] <kpiwko> ALR: ok
[20:02:12] <kpiwko> ALR: as I said, the most important for me it to have stable API which does not change under my hands...I'm already using arquillian/shrinkwrap/arquillian-selenium heavily and because all required functionality is in snapshots only, keeping it running simply is a *big* overhead
[20:02:50] <kpiwko> having at least one of the project released asap would save me a lot of headaches and curses
[20:02:51] <ALR> kpiwko: We're going for Beta for just that reason.
[20:03:27] <kpiwko> still, a week delay is not something I can't get over
[20:04:07] <kpiwko> ALR: I've just checked https://issues.jboss.org/browse/SHRINKWRAP/fixforversion/12314103, seems like quite a lot of stuff to be done yet
[20:05:01] <kpiwko> having it at the end of january would be awesome, as I'd like to see ARQ beta-1 as well within a month
[20:08:26] <kpiwko> ALR: what about making the Resolvers name a SW specific?
[20:08:36] <kpiwko> ALR: something like ShrinkPack
[20:09:51] <ALR> kpiwko: It's a module, not a project.
[20:10:28] <ALR> IMO modules should get descriptive names.  Else it becomes difficult to know what the intent is.
[20:10:50] <ALR> Like: What is "jboss-ejb3-effigy"?
[20:11:00] <ALR> It's a metadata adaptor.  But you'd never know that. :P
[20:11:11] <kpiwko> ALR: that's a shame...I've just find out Polymer :)
[20:11:33] <ALR> Would never pass legal :)
[20:11:48] <ALR> (We approve all project names through a vetting process)
[20:12:05] <kpiwko> ALR: that's right...they keep refusing most of the names we create
[20:12:19] <kpiwko> such us Cheiron, Lupic, etc
[20:12:23] <ALR> Not all.  Only the good ones.
[20:12:58] <kpiwko> was SW name intended to hold a different name as well?
[20:13:32] <ALR> kpiwko: Hold?
[20:14:20] <kpiwko> ALR: I meant if there was an intention to call it differently before ShrinkWrap was accepted...
[20:14:27] <ALR> kpiwko: Oh, no.
[20:14:38] <ALR> We had placeholder names.
[20:14:50] <ALR> Then a list we submitted to legal and voted on in the community.
[20:15:07] <ALR> Originally it was "Declarative Archives"
[20:15:17] <ALR> Which is funny because they're not declarative.
[20:15:26] <kpiwko> :D
[20:16:14] *** jharting1 has joined #jbosstesting
[20:16:54] *** michaelschuetz has joined #jbosstesting
[20:18:35] *** jharting has quit IRC
[20:21:15] *** jdewinne has joined #jbosstesting
[20:23:27] *** michaelschuetz1 has joined #jbosstesting
[20:24:01] *** michaelschuetz has quit IRC
[20:24:41] *** michaelschuetz has joined #jbosstesting
[20:28:07] <ALR> kpiwko: DependencyException.  Unchecked?
[20:28:21] *** michaelschuetz1 has quit IRC
[20:28:32] <ALR> I suppose a user wouldn't be expecting to recover from a failed resolution request.
[20:30:36] <kpiwko> ALR: AFAIR the Aether exceptions are unchecked as well
[20:30:57] <ALR> kpiwko: Unchecked is right I think
[20:31:05] * ALR back in a bit.
[20:31:44] *** michaelschuetz1 has joined #jbosstesting
[20:33:47] *** michaelschuetz has quit IRC
[20:48:28] *** jpederse has joined #jbosstesting
[20:48:50] *** jpederse has left #jbosstesting
[20:51:29] *** michaelschuetz has joined #jbosstesting
[20:55:30] *** michaelschuetz1 has quit IRC
[21:13:29] *** oskutka has joined #jbosstesting
[21:23:06] *** oskutka has quit IRC
[21:24:11] *** jdewinne has quit IRC
[21:41:29] *** mgoldmann has quit IRC
[21:42:43] *** dblevins has quit IRC
[21:43:54] *** jdlee has quit IRC
[21:44:17] *** jdlee has joined #jbosstesting
[22:08:47] *** bleathem has joined #jbosstesting
[22:13:44] *** michaelschuetz has quit IRC
[22:46:28] *** kpiwko has quit IRC
[22:47:56] *** michaelschuetz has joined #jbosstesting
[23:00:14] *** michaelschuetz has quit IRC
[23:22:33] *** maeste has quit IRC
[23:26:23] *** jeand has quit IRC
[23:46:39] *** jharting1 has left #jbosstesting





top