From issues at jboss.org Mon May 4 12:45:45 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 4 May 2015 12:45:45 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-684) Create standalone appliance using Wildfly Swarm In-Reply-To: References: Message-ID: Brett Meyer created ARTIF-684: --------------------------------- Summary: Create standalone appliance using Wildfly Swarm Key: ARTIF-684 URL: https://issues.jboss.org/browse/ARTIF-684 Project: Artificer Issue Type: Feature Request Reporter: Brett Meyer Assignee: Brett Meyer https://github.com/wildfly-swarm/wildfly-swarm -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon May 4 12:46:45 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 4 May 2015 12:46:45 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-673) Create a stripped-down distro for use on any app server In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13065138#comment-13065138 ] Brett Meyer commented on ARTIF-673: ----------------------------------- Rejecting. Instead, going to focus on Wildfly only. In addition, building a standalone appliance using ARTIF-684 > Create a stripped-down distro for use on any app server > ------------------------------------------------------- > > Key: ARTIF-673 > URL: https://issues.jboss.org/browse/ARTIF-673 > Project: Artificer > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > > Realistically, there should be no reason why we couldn't rely on embedded modeshape, simple BASIC auth, etc. for a really stripped-down distro. Think of it as a simplified "headless" mode of sorts. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon May 4 12:46:45 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 4 May 2015 12:46:45 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-673) Create a stripped-down distro for use on any app server In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer closed ARTIF-673. ----------------------------- Resolution: Won't Fix > Create a stripped-down distro for use on any app server > ------------------------------------------------------- > > Key: ARTIF-673 > URL: https://issues.jboss.org/browse/ARTIF-673 > Project: Artificer > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > > Realistically, there should be no reason why we couldn't rely on embedded modeshape, simple BASIC auth, etc. for a really stripped-down distro. Think of it as a simplified "headless" mode of sorts. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu May 7 11:37:45 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 7 May 2015 11:37:45 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-685) OSGi Bundle Repository In-Reply-To: References: Message-ID: Brett Meyer created ARTIF-685: --------------------------------- Summary: OSGi Bundle Repository Key: ARTIF-685 URL: https://issues.jboss.org/browse/ARTIF-685 Project: Artificer Issue Type: Feature Request Reporter: Brett Meyer Assignee: Brett Meyer In addition to the Maven Facade, add support that would position Artificer as an OSGi Bundle Repository (OBR). It's not much different from a typical maven repo, but utilizes OSGi-specific XML resource files, etc. for provisioning within OSGi runtimes. http://www.osgi.org/Repository/HomePage http://felix.apache.org/documentation/subprojects/apache-felix-osgi-bundle-repository.html http://njbartlett.name/2011/09/12/why-obr.html -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu May 7 18:51:45 2015 From: issues at jboss.org (Howard Pearlmutter (JIRA)) Date: Thu, 7 May 2015 18:51:45 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-683) Switch to RDBMS, Hibernate ORM, Hibernate Search, and Hibernate 2nd Level Cache as the persistence solution In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13066388#comment-13066388 ] Howard Pearlmutter commented on ARTIF-683: ------------------------------------------ Hey, this is JBoss land -- and the open standard for this kind of thing is JPA :) Use JPA, which wraps HibernateORM etc, and then any RDBMS can be plugged in behind that. Then Hiberante OGM comes essentially for free. That lets you use the same JPA interface, but plug NoSQL DBs in behind. Then consider that the reason for Artificer using JCR ought to be less about hierarchical structure, and more about the already-well-architected rich support for content/documents/artifacts. Many potential Artificer users (such as myself) will want that extra functionality (for example, I want my SRAMP content to cohabit with my non-SRAMP content, and be able to write code to exploit colocation synergies, and to exploit JCR/Modeshape functionality.) Modeshape has very rich relational and network capability (internally it's has a generalized graph topology, not just hierarchical), and is a much higher level developer interface onto both relational and filesystem abstractions -- so your whole argument really only boils down to a matter of runtime efficiencies (storage space & execution speed). I've worked with the JBoss ecosystem now for 15 years (since EJBoss in 1999). And I've advised many CIOs, architects, and developers on questions like this. I strongly suggest you see Artificer as a very high level functional application for business organizations and technical organizations, rather than yet-another-low-level-engine (of which there are hundreds and hundreds). While space and time efficiency are always important, they don't make the top 10 list of what CIOs (should, and do) consider critical -- such as reliability, manageability, scalability, security, longevity, stability, developer ease, etc. So architect with the key longterm open standards; don't strip down and try to hotrod. Instead of stripdown hotrodding, go Architectural. Architecturally, for speed, you'll want ISPN (which, BTW, has a fast API called Hotrod ;)). Hibernate caching is done with ISPN. Modeshape sits on ISPN. ISPN can be backed with *anything* (JDBC/RDBMS, NoSQL, JClouds/S3, etc) as long as a CacheStore is written. Most importantly, stick with open standards, so you let your users (like me) make our own best decision of what to put behind the standard interface. So it boils down to JPA & JCR. The real interesting point here is the opportunity to combine the 2 in an intelligent way to leverage the best of each. Side-by-side is possible, but there are other more interesting approaches to consider. JCR can back onto JPA, via ISPN CacheStore. (Tunnelling or bypassing then become options for your code that needs to get directly at relational for efficiency reasons.) JPA can back onto JCR --- here are a few to consider -- https://code.google.com/p/jpa4jcr https://github.com/Kobee1203/jcrom --- and then you can have nice integrity between the 2 paradigms. (&/or tunnel, or bypass, or best *tune* when you need performance) IMHO, you ought to have a chat with Randall and figure out an optimal architecture. FYI, I came to Artificer for the Errai, and stayed (so far) for the ModeShape ;) > Switch to RDBMS, Hibernate ORM, Hibernate Search, and Hibernate 2nd Level Cache as the persistence solution > ----------------------------------------------------------------------------------------------------------- > > Key: ARTIF-683 > URL: https://issues.jboss.org/browse/ARTIF-683 > Project: Artificer > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > > Artificer currently uses ModeShape + Infinispan + JDBC as its storage. Back when Artificer was a simple S-RAMP impl, JCR made a lot of sense. The S-RAMP spec is essentially a hierarchical artifact repo that maintains the node metadata and relationships between them. However, the "hierarchical" bit is overstated -- it's limited to a primary artifact and its derived artifact (ex -- primary: XSD, derived: type declarations). So, the hierarchy is at most 2 levels and could be represented by a simple relationship or one-to-one foreign key. The only time the hierarchical structure is helpful is when we look up an artifact by its UUID (due to a specific tree structure we use). But otherwise, I think it's a bit of a misnomer. > We're now extending well beyond S-RAMP. In addition to an artifact/metadata/info repo, we're trying to position the project as a more general repo for multiple projects and service information. Most importantly, the relationship requirements will expand the most. As such, I'm thinking we'd be better served by alternatives. > Note that this is essentially a read-intensive system. Writes do of course occur, but they're almost always *additions*. Nodes are rarely updated once created. Locking and isolation should be used, but can be extremely optimistic. Also note that most artifacts have files with them. That currently uses a local filesystem store through ISPN, but could certainly be NAS. > Additional fuel for the fire: many enterprise-level development shops have millions of artifacts, exponentially higher once derivation kicks in. Further, many have multiple relationships defined. > Ideas: > 1.) Switch to RDBMS + Hibernate ORM + Hibernate Search + Hibernate 2nd Level Caching. Although the structure originally looked JCR-specific, it may make a lot more sense as a relational DB. HSearch is a no brainer -- the full-text search capability would be vastly improved, right out of the box. And the RDBMS + in-memory-cache would be perfect for the read-intensive environment and scalability. > 2.) Graph databases: Neo4j (w/ or w/o Hibernate OGM), OrientDB, etc.. The concern here is mainly horizontal scaling and, from what I understand, their (lack of adequate) clustering support. But, it's definitely an option. > 3.) Distributed but strongly consistent database: RocksDB (a variant of LevelDB), CockroachDB. These are newer, but can (theoretically) scale larger than relational, and because they replicate data it might be more durable or at least recover faster in the event of failure. On the other hand, this may be more difficult for enterprises to adopt > 3.) Stick with MS + ISPN, but use Cassandra behind it (instead of JDBC). Arguably, this wouldn't really change things and could potentially end up worse. > 4.) Tinkerpop/Blueprints (graph API). Hawkular is using this. However, from what I've heard elsewhere, it's a horrible standard. Solutions that attempt to implement it end up in a state of twisted adaptation, resulting in performance hits. > In the end, I'd argue that #1 is the best from enterprise-level, scalability, reliability, and configurability standpoints. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu May 7 18:51:46 2015 From: issues at jboss.org (Howard Pearlmutter (JIRA)) Date: Thu, 7 May 2015 18:51:46 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-683) Switch to RDBMS, Hibernate ORM, Hibernate Search, and Hibernate 2nd Level Cache as the persistence solution In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13066388#comment-13066388 ] Howard Pearlmutter edited comment on ARTIF-683 at 5/7/15 6:51 PM: ------------------------------------------------------------------ Hey Brett, this is JBoss land -- and the open standard for this kind of thing is JPA :) Use JPA, which wraps HibernateORM etc, and then any RDBMS can be plugged in behind that. Then Hiberante OGM comes essentially for free. That lets you use the same JPA interface, but plug NoSQL DBs in behind. Then consider that the reason for Artificer using JCR ought to be less about hierarchical structure, and more about the already-well-architected rich support for content/documents/artifacts. Many potential Artificer users (such as myself) will want that extra functionality (for example, I want my SRAMP content to cohabit with my non-SRAMP content, and be able to write code to exploit colocation synergies, and to exploit JCR/Modeshape functionality.) Modeshape has very rich relational and network capability (internally it's has a generalized graph topology, not just hierarchical), and is a much higher level developer interface onto both relational and filesystem abstractions -- so your whole argument really only boils down to a matter of runtime efficiencies (storage space & execution speed). I've worked with the JBoss ecosystem now for 15 years (since EJBoss in 1999). And I've advised many CIOs, architects, and developers on questions like this. I strongly suggest you see Artificer as a very high level functional application for business organizations and technical organizations, rather than yet-another-low-level-engine (of which there are hundreds and hundreds). While space and time efficiency are always important, they don't make the top 10 list of what CIOs (should, and do) consider critical -- such as reliability, manageability, scalability, security, longevity, stability, developer ease, etc. So architect with the key longterm open standards; don't strip down and try to hotrod. Instead of stripdown hotrodding, go Architectural. Architecturally, for speed, you'll want ISPN (which, BTW, has a fast API called Hotrod ;)). Hibernate caching is done with ISPN. Modeshape sits on ISPN. ISPN can be backed with *anything* (JDBC/RDBMS, NoSQL, JClouds/S3, etc) as long as a CacheStore is written. Most importantly, stick with open standards, so you let your users (like me) make our own best decision of what to put behind the standard interface. So it boils down to JPA & JCR. The real interesting point here is the opportunity to combine the 2 in an intelligent way to leverage the best of each. Side-by-side is possible, but there are other more interesting approaches to consider. JCR can back onto JPA, via ISPN CacheStore. (Tunnelling or bypassing then become options for your code that needs to get directly at relational for efficiency reasons.) JPA can back onto JCR --- here are a few to consider -- https://code.google.com/p/jpa4jcr https://github.com/Kobee1203/jcrom --- and then you can have nice integrity between the 2 paradigms. (&/or tunnel, or bypass, or best *tune* when you need performance) IMHO, you ought to have a chat with Randall and figure out an optimal architecture. FYI, I came to Artificer for the Errai, and stayed (so far) for the ModeShape ;) was (Author: hxp): Hey, this is JBoss land -- and the open standard for this kind of thing is JPA :) Use JPA, which wraps HibernateORM etc, and then any RDBMS can be plugged in behind that. Then Hiberante OGM comes essentially for free. That lets you use the same JPA interface, but plug NoSQL DBs in behind. Then consider that the reason for Artificer using JCR ought to be less about hierarchical structure, and more about the already-well-architected rich support for content/documents/artifacts. Many potential Artificer users (such as myself) will want that extra functionality (for example, I want my SRAMP content to cohabit with my non-SRAMP content, and be able to write code to exploit colocation synergies, and to exploit JCR/Modeshape functionality.) Modeshape has very rich relational and network capability (internally it's has a generalized graph topology, not just hierarchical), and is a much higher level developer interface onto both relational and filesystem abstractions -- so your whole argument really only boils down to a matter of runtime efficiencies (storage space & execution speed). I've worked with the JBoss ecosystem now for 15 years (since EJBoss in 1999). And I've advised many CIOs, architects, and developers on questions like this. I strongly suggest you see Artificer as a very high level functional application for business organizations and technical organizations, rather than yet-another-low-level-engine (of which there are hundreds and hundreds). While space and time efficiency are always important, they don't make the top 10 list of what CIOs (should, and do) consider critical -- such as reliability, manageability, scalability, security, longevity, stability, developer ease, etc. So architect with the key longterm open standards; don't strip down and try to hotrod. Instead of stripdown hotrodding, go Architectural. Architecturally, for speed, you'll want ISPN (which, BTW, has a fast API called Hotrod ;)). Hibernate caching is done with ISPN. Modeshape sits on ISPN. ISPN can be backed with *anything* (JDBC/RDBMS, NoSQL, JClouds/S3, etc) as long as a CacheStore is written. Most importantly, stick with open standards, so you let your users (like me) make our own best decision of what to put behind the standard interface. So it boils down to JPA & JCR. The real interesting point here is the opportunity to combine the 2 in an intelligent way to leverage the best of each. Side-by-side is possible, but there are other more interesting approaches to consider. JCR can back onto JPA, via ISPN CacheStore. (Tunnelling or bypassing then become options for your code that needs to get directly at relational for efficiency reasons.) JPA can back onto JCR --- here are a few to consider -- https://code.google.com/p/jpa4jcr https://github.com/Kobee1203/jcrom --- and then you can have nice integrity between the 2 paradigms. (&/or tunnel, or bypass, or best *tune* when you need performance) IMHO, you ought to have a chat with Randall and figure out an optimal architecture. FYI, I came to Artificer for the Errai, and stayed (so far) for the ModeShape ;) > Switch to RDBMS, Hibernate ORM, Hibernate Search, and Hibernate 2nd Level Cache as the persistence solution > ----------------------------------------------------------------------------------------------------------- > > Key: ARTIF-683 > URL: https://issues.jboss.org/browse/ARTIF-683 > Project: Artificer > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > > Artificer currently uses ModeShape + Infinispan + JDBC as its storage. Back when Artificer was a simple S-RAMP impl, JCR made a lot of sense. The S-RAMP spec is essentially a hierarchical artifact repo that maintains the node metadata and relationships between them. However, the "hierarchical" bit is overstated -- it's limited to a primary artifact and its derived artifact (ex -- primary: XSD, derived: type declarations). So, the hierarchy is at most 2 levels and could be represented by a simple relationship or one-to-one foreign key. The only time the hierarchical structure is helpful is when we look up an artifact by its UUID (due to a specific tree structure we use). But otherwise, I think it's a bit of a misnomer. > We're now extending well beyond S-RAMP. In addition to an artifact/metadata/info repo, we're trying to position the project as a more general repo for multiple projects and service information. Most importantly, the relationship requirements will expand the most. As such, I'm thinking we'd be better served by alternatives. > Note that this is essentially a read-intensive system. Writes do of course occur, but they're almost always *additions*. Nodes are rarely updated once created. Locking and isolation should be used, but can be extremely optimistic. Also note that most artifacts have files with them. That currently uses a local filesystem store through ISPN, but could certainly be NAS. > Additional fuel for the fire: many enterprise-level development shops have millions of artifacts, exponentially higher once derivation kicks in. Further, many have multiple relationships defined. > Ideas: > 1.) Switch to RDBMS + Hibernate ORM + Hibernate Search + Hibernate 2nd Level Caching. Although the structure originally looked JCR-specific, it may make a lot more sense as a relational DB. HSearch is a no brainer -- the full-text search capability would be vastly improved, right out of the box. And the RDBMS + in-memory-cache would be perfect for the read-intensive environment and scalability. > 2.) Graph databases: Neo4j (w/ or w/o Hibernate OGM), OrientDB, etc.. The concern here is mainly horizontal scaling and, from what I understand, their (lack of adequate) clustering support. But, it's definitely an option. > 3.) Distributed but strongly consistent database: RocksDB (a variant of LevelDB), CockroachDB. These are newer, but can (theoretically) scale larger than relational, and because they replicate data it might be more durable or at least recover faster in the event of failure. On the other hand, this may be more difficult for enterprises to adopt > 3.) Stick with MS + ISPN, but use Cassandra behind it (instead of JDBC). Arguably, this wouldn't really change things and could potentially end up worse. > 4.) Tinkerpop/Blueprints (graph API). Hawkular is using this. However, from what I've heard elsewhere, it's a horrible standard. Solutions that attempt to implement it end up in a state of twisted adaptation, resulting in performance hits. > In the end, I'd argue that #1 is the best from enterprise-level, scalability, reliability, and configurability standpoints. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu May 7 19:02:45 2015 From: issues at jboss.org (Howard Pearlmutter (JIRA)) Date: Thu, 7 May 2015 19:02:45 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-683) Switch to RDBMS, Hibernate ORM, Hibernate Search, and Hibernate 2nd Level Cache as the persistence solution In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13066388#comment-13066388 ] Howard Pearlmutter edited comment on ARTIF-683 at 5/7/15 7:02 PM: ------------------------------------------------------------------ Hey Brett, this is JBoss land -- and the open standard for this kind of thing is JPA :) Use JPA, which wraps HibernateORM etc, and then any RDBMS can be plugged in behind that. Then Hiberante OGM comes essentially for free. That lets you use the same JPA interface, but plug NoSQL DBs in behind. Then consider that the reason for Artificer using JCR ought to be less about hierarchical structure, and more about the already-well-architected rich support for content/documents/artifacts. Many potential Artificer users (such as myself) will want that extra functionality (for example, I want my SRAMP content to cohabit with my non-SRAMP content, and be able to write code to exploit colocation synergies, and to exploit JCR/Modeshape functionality.) Modeshape has very rich relational and network capability (internally it's has a generalized graph topology, not just hierarchical), and is a much higher level developer interface onto both relational and filesystem abstractions -- so your whole argument really only boils down to a matter of runtime efficiencies (storage space & execution speed). I've worked with the JBoss ecosystem now for 15 years (since EJBoss in 1999). And I've advised many CIOs, architects, and developers on questions like this. I strongly suggest you see Artificer as a relatively high level functional application platform for business organizations and technical organizations, rather than yet-another-lower-level-engine (of which there are hundreds and hundreds). While space and time efficiency are always important, they don't make the top 10 list of what CIOs (should, and do) consider critical -- such as reliability, manageability, scalability, security, longevity, stability, developer ease, etc. So architect with the key longterm open standards; don't strip down and try to hotrod. Instead of stripdown hotrodding, go Architectural. Architecturally, for speed, you'll want ISPN (which, BTW, has a fast API called Hotrod ;)). Hibernate caching is done with ISPN. Modeshape sits on ISPN. ISPN can be backed with *anything* (JDBC/RDBMS, NoSQL, JClouds/S3, etc) as long as a CacheStore is written. Most importantly, stick with open standards, so you let your users (like me) make our own best decision of what to put behind the standard interface. So it boils down to JPA & JCR. The real interesting point here is the opportunity to combine the 2 in an intelligent way to leverage the best of each. Side-by-side is possible, but there are other more interesting approaches to consider. JCR can back onto JPA, via ISPN CacheStore. (Tunnelling or bypassing then become options for your code that needs to get directly at relational for efficiency reasons.) JPA can back onto JCR --- here are a few to consider -- https://code.google.com/p/jpa4jcr https://github.com/Kobee1203/jcrom --- and then you can have nice integrity between the 2 paradigms. (&/or tunnel, or bypass, or best *tune* when you need performance) IMHO, you ought to have a chat with Randall and figure out an optimal architecture. FYI, I came to Artificer for the Errai, and stayed (so far) for the ModeShape ;) was (Author: hxp): Hey Brett, this is JBoss land -- and the open standard for this kind of thing is JPA :) Use JPA, which wraps HibernateORM etc, and then any RDBMS can be plugged in behind that. Then Hiberante OGM comes essentially for free. That lets you use the same JPA interface, but plug NoSQL DBs in behind. Then consider that the reason for Artificer using JCR ought to be less about hierarchical structure, and more about the already-well-architected rich support for content/documents/artifacts. Many potential Artificer users (such as myself) will want that extra functionality (for example, I want my SRAMP content to cohabit with my non-SRAMP content, and be able to write code to exploit colocation synergies, and to exploit JCR/Modeshape functionality.) Modeshape has very rich relational and network capability (internally it's has a generalized graph topology, not just hierarchical), and is a much higher level developer interface onto both relational and filesystem abstractions -- so your whole argument really only boils down to a matter of runtime efficiencies (storage space & execution speed). I've worked with the JBoss ecosystem now for 15 years (since EJBoss in 1999). And I've advised many CIOs, architects, and developers on questions like this. I strongly suggest you see Artificer as a very high level functional application for business organizations and technical organizations, rather than yet-another-low-level-engine (of which there are hundreds and hundreds). While space and time efficiency are always important, they don't make the top 10 list of what CIOs (should, and do) consider critical -- such as reliability, manageability, scalability, security, longevity, stability, developer ease, etc. So architect with the key longterm open standards; don't strip down and try to hotrod. Instead of stripdown hotrodding, go Architectural. Architecturally, for speed, you'll want ISPN (which, BTW, has a fast API called Hotrod ;)). Hibernate caching is done with ISPN. Modeshape sits on ISPN. ISPN can be backed with *anything* (JDBC/RDBMS, NoSQL, JClouds/S3, etc) as long as a CacheStore is written. Most importantly, stick with open standards, so you let your users (like me) make our own best decision of what to put behind the standard interface. So it boils down to JPA & JCR. The real interesting point here is the opportunity to combine the 2 in an intelligent way to leverage the best of each. Side-by-side is possible, but there are other more interesting approaches to consider. JCR can back onto JPA, via ISPN CacheStore. (Tunnelling or bypassing then become options for your code that needs to get directly at relational for efficiency reasons.) JPA can back onto JCR --- here are a few to consider -- https://code.google.com/p/jpa4jcr https://github.com/Kobee1203/jcrom --- and then you can have nice integrity between the 2 paradigms. (&/or tunnel, or bypass, or best *tune* when you need performance) IMHO, you ought to have a chat with Randall and figure out an optimal architecture. FYI, I came to Artificer for the Errai, and stayed (so far) for the ModeShape ;) > Switch to RDBMS, Hibernate ORM, Hibernate Search, and Hibernate 2nd Level Cache as the persistence solution > ----------------------------------------------------------------------------------------------------------- > > Key: ARTIF-683 > URL: https://issues.jboss.org/browse/ARTIF-683 > Project: Artificer > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > > Artificer currently uses ModeShape + Infinispan + JDBC as its storage. Back when Artificer was a simple S-RAMP impl, JCR made a lot of sense. The S-RAMP spec is essentially a hierarchical artifact repo that maintains the node metadata and relationships between them. However, the "hierarchical" bit is overstated -- it's limited to a primary artifact and its derived artifact (ex -- primary: XSD, derived: type declarations). So, the hierarchy is at most 2 levels and could be represented by a simple relationship or one-to-one foreign key. The only time the hierarchical structure is helpful is when we look up an artifact by its UUID (due to a specific tree structure we use). But otherwise, I think it's a bit of a misnomer. > We're now extending well beyond S-RAMP. In addition to an artifact/metadata/info repo, we're trying to position the project as a more general repo for multiple projects and service information. Most importantly, the relationship requirements will expand the most. As such, I'm thinking we'd be better served by alternatives. > Note that this is essentially a read-intensive system. Writes do of course occur, but they're almost always *additions*. Nodes are rarely updated once created. Locking and isolation should be used, but can be extremely optimistic. Also note that most artifacts have files with them. That currently uses a local filesystem store through ISPN, but could certainly be NAS. > Additional fuel for the fire: many enterprise-level development shops have millions of artifacts, exponentially higher once derivation kicks in. Further, many have multiple relationships defined. > Ideas: > 1.) Switch to RDBMS + Hibernate ORM + Hibernate Search + Hibernate 2nd Level Caching. Although the structure originally looked JCR-specific, it may make a lot more sense as a relational DB. HSearch is a no brainer -- the full-text search capability would be vastly improved, right out of the box. And the RDBMS + in-memory-cache would be perfect for the read-intensive environment and scalability. > 2.) Graph databases: Neo4j (w/ or w/o Hibernate OGM), OrientDB, etc.. The concern here is mainly horizontal scaling and, from what I understand, their (lack of adequate) clustering support. But, it's definitely an option. > 3.) Distributed but strongly consistent database: RocksDB (a variant of LevelDB), CockroachDB. These are newer, but can (theoretically) scale larger than relational, and because they replicate data it might be more durable or at least recover faster in the event of failure. On the other hand, this may be more difficult for enterprises to adopt > 3.) Stick with MS + ISPN, but use Cassandra behind it (instead of JDBC). Arguably, this wouldn't really change things and could potentially end up worse. > 4.) Tinkerpop/Blueprints (graph API). Hawkular is using this. However, from what I've heard elsewhere, it's a horrible standard. Solutions that attempt to implement it end up in a state of twisted adaptation, resulting in performance hits. > In the end, I'd argue that #1 is the best from enterprise-level, scalability, reliability, and configurability standpoints. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu May 7 19:11:45 2015 From: issues at jboss.org (Howard Pearlmutter (JIRA)) Date: Thu, 7 May 2015 19:11:45 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-683) Switch to RDBMS, Hibernate ORM, Hibernate Search, and Hibernate 2nd Level Cache as the persistence solution In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13066388#comment-13066388 ] Howard Pearlmutter edited comment on ARTIF-683 at 5/7/15 7:10 PM: ------------------------------------------------------------------ Hey Brett, this is JBoss land -- and the open standard for this kind of thing is JPA :) Use JPA, which wraps HibernateORM etc, and then any RDBMS can be plugged in behind that. Then Hiberante OGM comes essentially for free. That lets you use the same JPA interface, but plug NoSQL DBs in behind. Then consider that the reason for Artificer using JCR ought to be less about hierarchical structure, and more about the already-well-architected rich support for content/documents/artifacts. Many potential Artificer users (such as myself) will want that extra functionality (for example, I want my SRAMP content to cohabit with my non-SRAMP content, and be able to write code to exploit colocation synergies, and to exploit JCR/Modeshape functionality.) Modeshape has very rich relational and network capability (internally it's has a generalized graph topology, not just hierarchical), and is a much higher level developer interface onto both relational and filesystem abstractions -- so your whole argument really only boils down to a matter of runtime efficiencies (storage space & execution speed). I've worked with the JBoss ecosystem now for 15 years (since EJBoss in 1999). And I've advised many CIOs, architects, and developers on questions like this. I strongly suggest you see Artificer as a relatively high level functional application platform for business organizations and technical organizations, rather than yet-another-lower-level-engine (of which there are hundreds and hundreds). While space and time efficiency are always important, they don't make the top 10 list of what CIOs (should, and do) consider critical -- such as reliability, manageability, scalability, security, longevity, stability, developer ease, etc. So architect with the key longterm open standards; don't strip down and try to hotrod. Instead of stripdown hotrodding, go Architectural. Architecturally, for speed, you'll want ISPN (which, BTW, has a fast API called Hotrod ;)). Hibernate caching is done with ISPN. Modeshape sits on ISPN. ISPN can be backed with *anything* (JDBC/RDBMS, NoSQL, JClouds/S3, etc) as long as a CacheStore is written. Most importantly, stick with open standards, so you let your users (like me) make our own best decision of what to put behind the standard interface. So it boils down to JPA & JCR. The real interesting point here is the opportunity to combine the 2 in an intelligent way to leverage the best of each. Side-by-side is possible, but there are other more interesting approaches to consider. JCR can back onto JPA, via ISPN CacheStore. (Tunnelling or bypassing then become options for your code that needs to get directly at relational for efficiency reasons.) JPA can back onto JCR --- for example -- https://github.com/Kobee1203/jcrom --- and then you can have nice integrity between the 2 paradigms. (&/or tunnel, or bypass, or best *tune* when you need performance) IMHO, you ought to have a chat with Randall and figure out an optimal architecture. FYI, I came to Artificer for the Errai, and stayed (so far) for the ModeShape ;) was (Author: hxp): Hey Brett, this is JBoss land -- and the open standard for this kind of thing is JPA :) Use JPA, which wraps HibernateORM etc, and then any RDBMS can be plugged in behind that. Then Hiberante OGM comes essentially for free. That lets you use the same JPA interface, but plug NoSQL DBs in behind. Then consider that the reason for Artificer using JCR ought to be less about hierarchical structure, and more about the already-well-architected rich support for content/documents/artifacts. Many potential Artificer users (such as myself) will want that extra functionality (for example, I want my SRAMP content to cohabit with my non-SRAMP content, and be able to write code to exploit colocation synergies, and to exploit JCR/Modeshape functionality.) Modeshape has very rich relational and network capability (internally it's has a generalized graph topology, not just hierarchical), and is a much higher level developer interface onto both relational and filesystem abstractions -- so your whole argument really only boils down to a matter of runtime efficiencies (storage space & execution speed). I've worked with the JBoss ecosystem now for 15 years (since EJBoss in 1999). And I've advised many CIOs, architects, and developers on questions like this. I strongly suggest you see Artificer as a relatively high level functional application platform for business organizations and technical organizations, rather than yet-another-lower-level-engine (of which there are hundreds and hundreds). While space and time efficiency are always important, they don't make the top 10 list of what CIOs (should, and do) consider critical -- such as reliability, manageability, scalability, security, longevity, stability, developer ease, etc. So architect with the key longterm open standards; don't strip down and try to hotrod. Instead of stripdown hotrodding, go Architectural. Architecturally, for speed, you'll want ISPN (which, BTW, has a fast API called Hotrod ;)). Hibernate caching is done with ISPN. Modeshape sits on ISPN. ISPN can be backed with *anything* (JDBC/RDBMS, NoSQL, JClouds/S3, etc) as long as a CacheStore is written. Most importantly, stick with open standards, so you let your users (like me) make our own best decision of what to put behind the standard interface. So it boils down to JPA & JCR. The real interesting point here is the opportunity to combine the 2 in an intelligent way to leverage the best of each. Side-by-side is possible, but there are other more interesting approaches to consider. JCR can back onto JPA, via ISPN CacheStore. (Tunnelling or bypassing then become options for your code that needs to get directly at relational for efficiency reasons.) JPA can back onto JCR --- here are a few to consider -- https://code.google.com/p/jpa4jcr https://github.com/Kobee1203/jcrom --- and then you can have nice integrity between the 2 paradigms. (&/or tunnel, or bypass, or best *tune* when you need performance) IMHO, you ought to have a chat with Randall and figure out an optimal architecture. FYI, I came to Artificer for the Errai, and stayed (so far) for the ModeShape ;) > Switch to RDBMS, Hibernate ORM, Hibernate Search, and Hibernate 2nd Level Cache as the persistence solution > ----------------------------------------------------------------------------------------------------------- > > Key: ARTIF-683 > URL: https://issues.jboss.org/browse/ARTIF-683 > Project: Artificer > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > > Artificer currently uses ModeShape + Infinispan + JDBC as its storage. Back when Artificer was a simple S-RAMP impl, JCR made a lot of sense. The S-RAMP spec is essentially a hierarchical artifact repo that maintains the node metadata and relationships between them. However, the "hierarchical" bit is overstated -- it's limited to a primary artifact and its derived artifact (ex -- primary: XSD, derived: type declarations). So, the hierarchy is at most 2 levels and could be represented by a simple relationship or one-to-one foreign key. The only time the hierarchical structure is helpful is when we look up an artifact by its UUID (due to a specific tree structure we use). But otherwise, I think it's a bit of a misnomer. > We're now extending well beyond S-RAMP. In addition to an artifact/metadata/info repo, we're trying to position the project as a more general repo for multiple projects and service information. Most importantly, the relationship requirements will expand the most. As such, I'm thinking we'd be better served by alternatives. > Note that this is essentially a read-intensive system. Writes do of course occur, but they're almost always *additions*. Nodes are rarely updated once created. Locking and isolation should be used, but can be extremely optimistic. Also note that most artifacts have files with them. That currently uses a local filesystem store through ISPN, but could certainly be NAS. > Additional fuel for the fire: many enterprise-level development shops have millions of artifacts, exponentially higher once derivation kicks in. Further, many have multiple relationships defined. > Ideas: > 1.) Switch to RDBMS + Hibernate ORM + Hibernate Search + Hibernate 2nd Level Caching. Although the structure originally looked JCR-specific, it may make a lot more sense as a relational DB. HSearch is a no brainer -- the full-text search capability would be vastly improved, right out of the box. And the RDBMS + in-memory-cache would be perfect for the read-intensive environment and scalability. > 2.) Graph databases: Neo4j (w/ or w/o Hibernate OGM), OrientDB, etc.. The concern here is mainly horizontal scaling and, from what I understand, their (lack of adequate) clustering support. But, it's definitely an option. > 3.) Distributed but strongly consistent database: RocksDB (a variant of LevelDB), CockroachDB. These are newer, but can (theoretically) scale larger than relational, and because they replicate data it might be more durable or at least recover faster in the event of failure. On the other hand, this may be more difficult for enterprises to adopt > 3.) Stick with MS + ISPN, but use Cassandra behind it (instead of JDBC). Arguably, this wouldn't really change things and could potentially end up worse. > 4.) Tinkerpop/Blueprints (graph API). Hawkular is using this. However, from what I've heard elsewhere, it's a horrible standard. Solutions that attempt to implement it end up in a state of twisted adaptation, resulting in performance hits. > In the end, I'd argue that #1 is the best from enterprise-level, scalability, reliability, and configurability standpoints. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu May 7 19:13:46 2015 From: issues at jboss.org (Howard Pearlmutter (JIRA)) Date: Thu, 7 May 2015 19:13:46 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-683) Switch to RDBMS, Hibernate ORM, Hibernate Search, and Hibernate 2nd Level Cache as the persistence solution In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13066388#comment-13066388 ] Howard Pearlmutter edited comment on ARTIF-683 at 5/7/15 7:13 PM: ------------------------------------------------------------------ Hey Brett, this is JBoss land -- and the open standard for this kind of thing is JPA :) Use JPA, which wraps HibernateORM etc, and then any RDBMS can be plugged in behind that. Then Hiberante OGM comes essentially for free. That lets you use the same JPA interface, but plug NoSQL DBs in behind. Then consider that the reason for Artificer using JCR ought to be less about hierarchical structure, and more about the already-well-architected rich support for content/documents/artifacts. Many potential Artificer users (such as myself) will want that extra functionality (for example, I want my SRAMP content to cohabit with my non-SRAMP content, and be able to write code to exploit colocation synergies, and to exploit JCR/Modeshape functionality.) Modeshape has very rich relational and network capability (internally it's has a generalized graph topology, not just hierarchical), and is a much higher level developer interface onto both relational and filesystem abstractions -- so your whole argument really only boils down to a matter of runtime efficiencies (storage space & execution speed). I've worked with the JBoss ecosystem now for 15 years (since EJBoss in 1999). And I've advised many CIOs, architects, and developers on questions like this. I strongly suggest you see Artificer as a relatively high level functional application platform for business organizations and technical organizations, rather than yet-another-lower-level-engine (of which there are hundreds and hundreds). While space and time efficiency are always important, they don't make the top 10 list of what CIOs (should, and do) consider critical -- such as reliability, manageability, scalability, security, longevity, stability, developer ease, etc. So architect with the key longterm open standards; don't strip down and try to hotrod. Instead of stripdown hotrodding, go Architectural. Architecturally, for speed, you'll want ISPN (which, BTW, has a fast API called Hotrod ;)). Hibernate caching is done with ISPN. Modeshape sits on ISPN. ISPN can be backed with *anything* (JDBC/RDBMS, NoSQL, JClouds/S3, etc) as long as a CacheStore is written. Most importantly, stick with open standards, so you let your users (like me) make our own best decision of what to put behind the standard interface. So it boils down to JPA & JCR. The real interesting point here is the opportunity to combine the 2 in an intelligent way to leverage the best of each. Side-by-side is possible, but there are other more interesting approaches to consider. JCR can back onto JPA, via ISPN CacheStore. (Tunnelling or bypassing then become options for your code that needs to get directly at relational for efficiency reasons.) JPA POJOs could automatically back onto JCR --- for POC, see -- https://github.com/Kobee1203/jcrom --- and then you can have nice integrity between the 2 paradigms. (&/or tunnel, or bypass, or best *tune* when you need performance) IMHO, you ought to have a chat with Randall and figure out an optimal architecture. FYI, I came to Artificer for the Errai, and stayed (so far) for the ModeShape ;) was (Author: hxp): Hey Brett, this is JBoss land -- and the open standard for this kind of thing is JPA :) Use JPA, which wraps HibernateORM etc, and then any RDBMS can be plugged in behind that. Then Hiberante OGM comes essentially for free. That lets you use the same JPA interface, but plug NoSQL DBs in behind. Then consider that the reason for Artificer using JCR ought to be less about hierarchical structure, and more about the already-well-architected rich support for content/documents/artifacts. Many potential Artificer users (such as myself) will want that extra functionality (for example, I want my SRAMP content to cohabit with my non-SRAMP content, and be able to write code to exploit colocation synergies, and to exploit JCR/Modeshape functionality.) Modeshape has very rich relational and network capability (internally it's has a generalized graph topology, not just hierarchical), and is a much higher level developer interface onto both relational and filesystem abstractions -- so your whole argument really only boils down to a matter of runtime efficiencies (storage space & execution speed). I've worked with the JBoss ecosystem now for 15 years (since EJBoss in 1999). And I've advised many CIOs, architects, and developers on questions like this. I strongly suggest you see Artificer as a relatively high level functional application platform for business organizations and technical organizations, rather than yet-another-lower-level-engine (of which there are hundreds and hundreds). While space and time efficiency are always important, they don't make the top 10 list of what CIOs (should, and do) consider critical -- such as reliability, manageability, scalability, security, longevity, stability, developer ease, etc. So architect with the key longterm open standards; don't strip down and try to hotrod. Instead of stripdown hotrodding, go Architectural. Architecturally, for speed, you'll want ISPN (which, BTW, has a fast API called Hotrod ;)). Hibernate caching is done with ISPN. Modeshape sits on ISPN. ISPN can be backed with *anything* (JDBC/RDBMS, NoSQL, JClouds/S3, etc) as long as a CacheStore is written. Most importantly, stick with open standards, so you let your users (like me) make our own best decision of what to put behind the standard interface. So it boils down to JPA & JCR. The real interesting point here is the opportunity to combine the 2 in an intelligent way to leverage the best of each. Side-by-side is possible, but there are other more interesting approaches to consider. JCR can back onto JPA, via ISPN CacheStore. (Tunnelling or bypassing then become options for your code that needs to get directly at relational for efficiency reasons.) JPA can back onto JCR --- for example -- https://github.com/Kobee1203/jcrom --- and then you can have nice integrity between the 2 paradigms. (&/or tunnel, or bypass, or best *tune* when you need performance) IMHO, you ought to have a chat with Randall and figure out an optimal architecture. FYI, I came to Artificer for the Errai, and stayed (so far) for the ModeShape ;) > Switch to RDBMS, Hibernate ORM, Hibernate Search, and Hibernate 2nd Level Cache as the persistence solution > ----------------------------------------------------------------------------------------------------------- > > Key: ARTIF-683 > URL: https://issues.jboss.org/browse/ARTIF-683 > Project: Artificer > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > > Artificer currently uses ModeShape + Infinispan + JDBC as its storage. Back when Artificer was a simple S-RAMP impl, JCR made a lot of sense. The S-RAMP spec is essentially a hierarchical artifact repo that maintains the node metadata and relationships between them. However, the "hierarchical" bit is overstated -- it's limited to a primary artifact and its derived artifact (ex -- primary: XSD, derived: type declarations). So, the hierarchy is at most 2 levels and could be represented by a simple relationship or one-to-one foreign key. The only time the hierarchical structure is helpful is when we look up an artifact by its UUID (due to a specific tree structure we use). But otherwise, I think it's a bit of a misnomer. > We're now extending well beyond S-RAMP. In addition to an artifact/metadata/info repo, we're trying to position the project as a more general repo for multiple projects and service information. Most importantly, the relationship requirements will expand the most. As such, I'm thinking we'd be better served by alternatives. > Note that this is essentially a read-intensive system. Writes do of course occur, but they're almost always *additions*. Nodes are rarely updated once created. Locking and isolation should be used, but can be extremely optimistic. Also note that most artifacts have files with them. That currently uses a local filesystem store through ISPN, but could certainly be NAS. > Additional fuel for the fire: many enterprise-level development shops have millions of artifacts, exponentially higher once derivation kicks in. Further, many have multiple relationships defined. > Ideas: > 1.) Switch to RDBMS + Hibernate ORM + Hibernate Search + Hibernate 2nd Level Caching. Although the structure originally looked JCR-specific, it may make a lot more sense as a relational DB. HSearch is a no brainer -- the full-text search capability would be vastly improved, right out of the box. And the RDBMS + in-memory-cache would be perfect for the read-intensive environment and scalability. > 2.) Graph databases: Neo4j (w/ or w/o Hibernate OGM), OrientDB, etc.. The concern here is mainly horizontal scaling and, from what I understand, their (lack of adequate) clustering support. But, it's definitely an option. > 3.) Distributed but strongly consistent database: RocksDB (a variant of LevelDB), CockroachDB. These are newer, but can (theoretically) scale larger than relational, and because they replicate data it might be more durable or at least recover faster in the event of failure. On the other hand, this may be more difficult for enterprises to adopt > 3.) Stick with MS + ISPN, but use Cassandra behind it (instead of JDBC). Arguably, this wouldn't really change things and could potentially end up worse. > 4.) Tinkerpop/Blueprints (graph API). Hawkular is using this. However, from what I've heard elsewhere, it's a horrible standard. Solutions that attempt to implement it end up in a state of twisted adaptation, resulting in performance hits. > In the end, I'd argue that #1 is the best from enterprise-level, scalability, reliability, and configurability standpoints. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue May 12 10:13:20 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 12 May 2015 10:13:20 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-683) Switch to RDBMS, JPA (Hibernate), Hibernate Search, and Hibernate 2nd Level Cache as the default persistence solution In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-683: ------------------------------ Summary: Switch to RDBMS, JPA (Hibernate), Hibernate Search, and Hibernate 2nd Level Cache as the default persistence solution (was: Switch to RDBMS, Hibernate ORM, Hibernate Search, and Hibernate 2nd Level Cache as the persistence solution) > Switch to RDBMS, JPA (Hibernate), Hibernate Search, and Hibernate 2nd Level Cache as the default persistence solution > --------------------------------------------------------------------------------------------------------------------- > > Key: ARTIF-683 > URL: https://issues.jboss.org/browse/ARTIF-683 > Project: Artificer > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > > Artificer currently uses ModeShape + Infinispan + JDBC as its storage. Back when Artificer was a simple S-RAMP impl, JCR made a lot of sense. The S-RAMP spec is essentially a hierarchical artifact repo that maintains the node metadata and relationships between them. However, the "hierarchical" bit is overstated -- it's limited to a primary artifact and its derived artifact (ex -- primary: XSD, derived: type declarations). So, the hierarchy is at most 2 levels and could be represented by a simple relationship or one-to-one foreign key. The only time the hierarchical structure is helpful is when we look up an artifact by its UUID (due to a specific tree structure we use). But otherwise, I think it's a bit of a misnomer. > We're now extending well beyond S-RAMP. In addition to an artifact/metadata/info repo, we're trying to position the project as a more general repo for multiple projects and service information. Most importantly, the relationship requirements will expand the most. As such, I'm thinking we'd be better served by alternatives. > Note that this is essentially a read-intensive system. Writes do of course occur, but they're almost always *additions*. Nodes are rarely updated once created. Locking and isolation should be used, but can be extremely optimistic. Also note that most artifacts have files with them. That currently uses a local filesystem store through ISPN, but could certainly be NAS. > Additional fuel for the fire: many enterprise-level development shops have millions of artifacts, exponentially higher once derivation kicks in. Further, many have multiple relationships defined. > Ideas: > 1.) Switch to RDBMS + Hibernate ORM + Hibernate Search + Hibernate 2nd Level Caching. Although the structure originally looked JCR-specific, it may make a lot more sense as a relational DB. HSearch is a no brainer -- the full-text search capability would be vastly improved, right out of the box. And the RDBMS + in-memory-cache would be perfect for the read-intensive environment and scalability. > 2.) Graph databases: Neo4j (w/ or w/o Hibernate OGM), OrientDB, etc.. The concern here is mainly horizontal scaling and, from what I understand, their (lack of adequate) clustering support. But, it's definitely an option. > 3.) Distributed but strongly consistent database: RocksDB (a variant of LevelDB), CockroachDB. These are newer, but can (theoretically) scale larger than relational, and because they replicate data it might be more durable or at least recover faster in the event of failure. On the other hand, this may be more difficult for enterprises to adopt > 3.) Stick with MS + ISPN, but use Cassandra behind it (instead of JDBC). Arguably, this wouldn't really change things and could potentially end up worse. > 4.) Tinkerpop/Blueprints (graph API). Hawkular is using this. However, from what I've heard elsewhere, it's a horrible standard. Solutions that attempt to implement it end up in a state of twisted adaptation, resulting in performance hits. > In the end, I'd argue that #1 is the best from enterprise-level, scalability, reliability, and configurability standpoints. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue May 12 10:13:21 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 12 May 2015 10:13:21 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-683) Switch to RDBMS, JPA (Hibernate), Hibernate Search, and Hibernate 2nd Level Cache as the default persistence solution In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-683: ------------------------------ Description: Artificer currently uses ModeShape + Infinispan + JDBC as its storage. Back when Artificer was a simple S-RAMP impl, JCR made a lot of sense. The S-RAMP spec is essentially a hierarchical artifact repo that maintains the node metadata and relationships between them. However, the "hierarchical" bit is overstated -- it's limited to a primary artifact and its derived artifact (ex -- primary: XSD, derived: type declarations). So, the hierarchy is at most 2 levels and could be represented by a simple relationship or one-to-one foreign key. The only time the hierarchical structure is helpful is when we look up an artifact by its UUID (due to a specific tree structure we use). But otherwise, I think it's a bit of a misnomer. We're now extending well beyond S-RAMP. In addition to an artifact/metadata/info repo, we're trying to position the project as a more general repo for multiple projects and service information. Most importantly, the relationship requirements will expand the most. As such, I'm thinking we'd be better served by alternatives. Note that this is essentially a read-intensive system. Writes do of course occur, but they're almost always *additions*. Nodes are rarely updated once created. Locking and isolation should be used, but can be extremely optimistic. Also note that most artifacts have files with them. That currently uses a local filesystem store through ISPN, but could certainly be NAS. Additional fuel for the fire: many enterprise-level development shops have millions of artifacts, exponentially higher once derivation kicks in. Further, many have multiple relationships defined. Ideas: 1.) Switch to RDBMS, JPA (Hibernate), Hibernate Search, and Hibernate 2nd Level Cache. Although the structure originally looked JCR-specific, it may make a lot more sense as a relational DB. HSearch is a no brainer -- the full-text search capability would be vastly improved, right out of the box. And the RDBMS + in-memory-cache would be perfect for the read-intensive environment and scalability. 2.) Graph databases: Neo4j (w/ or w/o Hibernate OGM), OrientDB, etc.. The concern here is mainly horizontal scaling and, from what I understand, their (lack of adequate) clustering support. But, it's definitely an option. 3.) Distributed but strongly consistent database: RocksDB (a variant of LevelDB), CockroachDB. These are newer, but can (theoretically) scale larger than relational, and because they replicate data it might be more durable or at least recover faster in the event of failure. On the other hand, this may be more difficult for enterprises to adopt 3.) Stick with MS + ISPN, but use Cassandra behind it (instead of JDBC). Arguably, this wouldn't really change things and could potentially end up worse. 4.) Tinkerpop/Blueprints (graph API). Hawkular is using this. However, from what I've heard elsewhere, it's a horrible standard. Solutions that attempt to implement it end up in a state of twisted adaptation, resulting in performance hits. In the end, I'd argue that #1 is the best from enterprise-level, scalability, reliability, and configurability standpoints. was: Artificer currently uses ModeShape + Infinispan + JDBC as its storage. Back when Artificer was a simple S-RAMP impl, JCR made a lot of sense. The S-RAMP spec is essentially a hierarchical artifact repo that maintains the node metadata and relationships between them. However, the "hierarchical" bit is overstated -- it's limited to a primary artifact and its derived artifact (ex -- primary: XSD, derived: type declarations). So, the hierarchy is at most 2 levels and could be represented by a simple relationship or one-to-one foreign key. The only time the hierarchical structure is helpful is when we look up an artifact by its UUID (due to a specific tree structure we use). But otherwise, I think it's a bit of a misnomer. We're now extending well beyond S-RAMP. In addition to an artifact/metadata/info repo, we're trying to position the project as a more general repo for multiple projects and service information. Most importantly, the relationship requirements will expand the most. As such, I'm thinking we'd be better served by alternatives. Note that this is essentially a read-intensive system. Writes do of course occur, but they're almost always *additions*. Nodes are rarely updated once created. Locking and isolation should be used, but can be extremely optimistic. Also note that most artifacts have files with them. That currently uses a local filesystem store through ISPN, but could certainly be NAS. Additional fuel for the fire: many enterprise-level development shops have millions of artifacts, exponentially higher once derivation kicks in. Further, many have multiple relationships defined. Ideas: 1.) Switch to RDBMS + Hibernate ORM + Hibernate Search + Hibernate 2nd Level Caching. Although the structure originally looked JCR-specific, it may make a lot more sense as a relational DB. HSearch is a no brainer -- the full-text search capability would be vastly improved, right out of the box. And the RDBMS + in-memory-cache would be perfect for the read-intensive environment and scalability. 2.) Graph databases: Neo4j (w/ or w/o Hibernate OGM), OrientDB, etc.. The concern here is mainly horizontal scaling and, from what I understand, their (lack of adequate) clustering support. But, it's definitely an option. 3.) Distributed but strongly consistent database: RocksDB (a variant of LevelDB), CockroachDB. These are newer, but can (theoretically) scale larger than relational, and because they replicate data it might be more durable or at least recover faster in the event of failure. On the other hand, this may be more difficult for enterprises to adopt 3.) Stick with MS + ISPN, but use Cassandra behind it (instead of JDBC). Arguably, this wouldn't really change things and could potentially end up worse. 4.) Tinkerpop/Blueprints (graph API). Hawkular is using this. However, from what I've heard elsewhere, it's a horrible standard. Solutions that attempt to implement it end up in a state of twisted adaptation, resulting in performance hits. In the end, I'd argue that #1 is the best from enterprise-level, scalability, reliability, and configurability standpoints. > Switch to RDBMS, JPA (Hibernate), Hibernate Search, and Hibernate 2nd Level Cache as the default persistence solution > --------------------------------------------------------------------------------------------------------------------- > > Key: ARTIF-683 > URL: https://issues.jboss.org/browse/ARTIF-683 > Project: Artificer > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > > Artificer currently uses ModeShape + Infinispan + JDBC as its storage. Back when Artificer was a simple S-RAMP impl, JCR made a lot of sense. The S-RAMP spec is essentially a hierarchical artifact repo that maintains the node metadata and relationships between them. However, the "hierarchical" bit is overstated -- it's limited to a primary artifact and its derived artifact (ex -- primary: XSD, derived: type declarations). So, the hierarchy is at most 2 levels and could be represented by a simple relationship or one-to-one foreign key. The only time the hierarchical structure is helpful is when we look up an artifact by its UUID (due to a specific tree structure we use). But otherwise, I think it's a bit of a misnomer. > We're now extending well beyond S-RAMP. In addition to an artifact/metadata/info repo, we're trying to position the project as a more general repo for multiple projects and service information. Most importantly, the relationship requirements will expand the most. As such, I'm thinking we'd be better served by alternatives. > Note that this is essentially a read-intensive system. Writes do of course occur, but they're almost always *additions*. Nodes are rarely updated once created. Locking and isolation should be used, but can be extremely optimistic. Also note that most artifacts have files with them. That currently uses a local filesystem store through ISPN, but could certainly be NAS. > Additional fuel for the fire: many enterprise-level development shops have millions of artifacts, exponentially higher once derivation kicks in. Further, many have multiple relationships defined. > Ideas: > 1.) Switch to RDBMS, JPA (Hibernate), Hibernate Search, and Hibernate 2nd Level Cache. Although the structure originally looked JCR-specific, it may make a lot more sense as a relational DB. HSearch is a no brainer -- the full-text search capability would be vastly improved, right out of the box. And the RDBMS + in-memory-cache would be perfect for the read-intensive environment and scalability. > 2.) Graph databases: Neo4j (w/ or w/o Hibernate OGM), OrientDB, etc.. The concern here is mainly horizontal scaling and, from what I understand, their (lack of adequate) clustering support. But, it's definitely an option. > 3.) Distributed but strongly consistent database: RocksDB (a variant of LevelDB), CockroachDB. These are newer, but can (theoretically) scale larger than relational, and because they replicate data it might be more durable or at least recover faster in the event of failure. On the other hand, this may be more difficult for enterprises to adopt > 3.) Stick with MS + ISPN, but use Cassandra behind it (instead of JDBC). Arguably, this wouldn't really change things and could potentially end up worse. > 4.) Tinkerpop/Blueprints (graph API). Hawkular is using this. However, from what I've heard elsewhere, it's a horrible standard. Solutions that attempt to implement it end up in a state of twisted adaptation, resulting in performance hits. > In the end, I'd argue that #1 is the best from enterprise-level, scalability, reliability, and configurability standpoints. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue May 12 10:48:19 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 12 May 2015 10:48:19 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-683) Switch to RDBMS, JPA (Hibernate), Hibernate Search, and Hibernate 2nd Level Cache as the default persistence solution In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13067326#comment-13067326 ] Brett Meyer commented on ARTIF-683: ----------------------------------- [~hxp], I should clarify: this isn't *replacing* the JCR plugin. For the time being, we'll continue to support that and you'll be able to continue using it. However, this new setup will be the new *default*. I'm obviously biased (I'm a committer and one of the core devs of Hibernate ORM), but this new setup has been a long time coming and has a large amount of benefits: - Horizontal scaling: Several potential users have brought up their typical enterprise-level use cases, and they all involved primary artifacts on the order of *one million*. Once derivation kicks in, that could look more like a hundred million, maybe more. I had a lot of concerns about JCR's ability to handle queries with that much data. RDBMS + proper indexing + in-mem caching has a proven track record... - CQRS pattern: Being able to query-by-column using pure SQL, rather than pulling out entire nodes (ala JCR), has a large amount of benefits on its own (http://martinfowler.com/bliki/CQRS.html). - Full-text search: Fully-indexed, full-text search is improving in ModeShape, but it's not quite there. Using Hibernate Search and Lucene opens the doors to several new features. - BLOB storage: I've actually added a new SPI that allows both SQL BLOB or the filesystem to be used for binary storage. For most use cases, BLOBs tend to have several pros over filesystem, so at least having it as an option is beneficial. Note that this SPI would also allow for new plugins: Ceph, Gluster, etc. - Flexibility: Right out of the gate, this tremendously increases what we're able to support. Any RDBMS (that's supported by Hibernate), any Hibernate caching solution (not limited to Infinispan), etc. - Less external dependencies: nearly the entire stack is already included in Wildfly/EAP out of the box {quote} Use JPA {quote} FWIW, I am using pure JPA, rather than Hibernate ORM. Although, the driving force behind that is mainly the JPA Criteria Query API... {quote} Then Hiberante OGM comes essentially for free. {quote} Definitely a fair point. OGM/NoSQL, Cassandra, GraphDBs, etc. could certainly be added as additional plugins, if the community wants them (and is willing to help develop them ;) {quote} so your whole argument really only boils down to a matter of runtime efficiencies (storage space & execution speed). {quote} Simply not true -- there's *a lot* more to it {quote} I strongly suggest you see Artificer as a relatively high level functional application platform for business organizations and technical organizations, rather than yet-another-lower-level-engine (of which there are hundreds and hundreds). While space and time efficiency are always important, they don't make the top 10 list of what CIOs (should, and do) consider critical ? such as reliability, manageability, scalability, security, longevity, stability, developer ease, etc. So architect with the key longterm open standards {quote} This is an absolutely vital point, and one that I focus on. Artificer needs to continue to become a powerful, out of the box application. It certainly needs to support developers and be usable as a powerful platform, but in the end, focusing on it as an *application* is where it will shine. But I'd argue that you're contradicting yourself, at least a bit. Through this tried-and-true stack, the "reliability, manageability, scalability, security, longevity, stability" increase across the board. And 80-90% of users will see the storage solution as simply an internal implementation detail. {quote} Instead of stripdown hotrodding, go Architectural {quote} Again, you're focusing only on the performance considerations, which are only a small piece of the decision. Realistically, we have a *long* backlog of tasks and new features to add, many of which would at least be difficult to support with JCR. A flexible architecture is definitely one area being gained... {quote} Most importantly, stick with open standards, so you let your users (like me) make our own best decision of what to put behind the standard interface. {quote} With JPA, that's what you'd be getting... {quote} and then you can have nice integrity between the 2 paradigms {quote} I have to say, I fully agree with Randall and Horia's points on https://developer.jboss.org/message/928792. Mixing JPA with JCR doesn't make much sense. {quote} IMHO, you ought to have a chat with Randall and figure out an optimal architecture. {quote} Myself, Randall, and several other committers on the Hibernate/Infinispan teams have been involved in these discussions and architecture. That should probably have been more in the open... I definitely value alternative opinions -- don't want this to sound like I'm just outright shooting you down. But, just wanted to clarify how this has shaped up. Feel free to continue the discussion! > Switch to RDBMS, JPA (Hibernate), Hibernate Search, and Hibernate 2nd Level Cache as the default persistence solution > --------------------------------------------------------------------------------------------------------------------- > > Key: ARTIF-683 > URL: https://issues.jboss.org/browse/ARTIF-683 > Project: Artificer > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > > Artificer currently uses ModeShape + Infinispan + JDBC as its storage. Back when Artificer was a simple S-RAMP impl, JCR made a lot of sense. The S-RAMP spec is essentially a hierarchical artifact repo that maintains the node metadata and relationships between them. However, the "hierarchical" bit is overstated -- it's limited to a primary artifact and its derived artifact (ex -- primary: XSD, derived: type declarations). So, the hierarchy is at most 2 levels and could be represented by a simple relationship or one-to-one foreign key. The only time the hierarchical structure is helpful is when we look up an artifact by its UUID (due to a specific tree structure we use). But otherwise, I think it's a bit of a misnomer. > We're now extending well beyond S-RAMP. In addition to an artifact/metadata/info repo, we're trying to position the project as a more general repo for multiple projects and service information. Most importantly, the relationship requirements will expand the most. As such, I'm thinking we'd be better served by alternatives. > Note that this is essentially a read-intensive system. Writes do of course occur, but they're almost always *additions*. Nodes are rarely updated once created. Locking and isolation should be used, but can be extremely optimistic. Also note that most artifacts have files with them. That currently uses a local filesystem store through ISPN, but could certainly be NAS. > Additional fuel for the fire: many enterprise-level development shops have millions of artifacts, exponentially higher once derivation kicks in. Further, many have multiple relationships defined. > Ideas: > 1.) Switch to RDBMS, JPA (Hibernate), Hibernate Search, and Hibernate 2nd Level Cache. Although the structure originally looked JCR-specific, it may make a lot more sense as a relational DB. HSearch is a no brainer -- the full-text search capability would be vastly improved, right out of the box. And the RDBMS + in-memory-cache would be perfect for the read-intensive environment and scalability. > 2.) Graph databases: Neo4j (w/ or w/o Hibernate OGM), OrientDB, etc.. The concern here is mainly horizontal scaling and, from what I understand, their (lack of adequate) clustering support. But, it's definitely an option. > 3.) Distributed but strongly consistent database: RocksDB (a variant of LevelDB), CockroachDB. These are newer, but can (theoretically) scale larger than relational, and because they replicate data it might be more durable or at least recover faster in the event of failure. On the other hand, this may be more difficult for enterprises to adopt > 3.) Stick with MS + ISPN, but use Cassandra behind it (instead of JDBC). Arguably, this wouldn't really change things and could potentially end up worse. > 4.) Tinkerpop/Blueprints (graph API). Hawkular is using this. However, from what I've heard elsewhere, it's a horrible standard. Solutions that attempt to implement it end up in a state of twisted adaptation, resulting in performance hits. > In the end, I'd argue that #1 is the best from enterprise-level, scalability, reliability, and configurability standpoints. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue May 12 11:01:24 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 12 May 2015 11:01:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-683) Switch to RDBMS, JPA (Hibernate), Hibernate Search, and Hibernate 2nd Level Cache as the default persistence solution In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13067326#comment-13067326 ] Brett Meyer edited comment on ARTIF-683 at 5/12/15 11:01 AM: ------------------------------------------------------------- [~hxp], I should clarify: this isn't currently *replacing* the JCR plugin. For the time being, we'll continue to support that and you'll be able to continue using it. But this new setup will be the new *default*. Further, in the future, I might still consider removing JCR altogether. That boils down to community needs, maintenance, and performance (ie, if there are situations JCR has an edge on JPA, great, but otherwise, there may not be reasons to keep it). I'm obviously biased (I'm a committer and one of the core devs of Hibernate ORM), but this new setup has been a long time coming and has a large amount of benefits: - Horizontal scaling: Several potential users have brought up their typical enterprise-level use cases, and they all involved primary artifacts on the order of *one million*. Once derivation kicks in, that could look more like a hundred million, maybe more. I had a lot of concerns about JCR's ability to handle queries with that much data. RDBMS + proper indexing + in-mem caching has a proven track record... - CQRS pattern: Being able to query-by-column using pure SQL, rather than pulling out entire nodes (ala JCR), has a large amount of benefits on its own (http://martinfowler.com/bliki/CQRS.html). - Full-text search: Fully-indexed, full-text search is improving in ModeShape, but it's not quite there. Using Hibernate Search and Lucene opens the doors to several new features. - BLOB storage: I've actually added a new SPI that allows both SQL BLOB or the filesystem to be used for binary storage. For most use cases, BLOBs tend to have several pros over filesystem, so at least having it as an option is beneficial. Note that this SPI would also allow for new plugins: Ceph, Gluster, etc. - Flexibility: Right out of the gate, this tremendously increases what we're able to support. Any RDBMS (that's supported by Hibernate), any Hibernate caching solution (not limited to Infinispan), etc. - Less external dependencies: nearly the entire stack is already included in Wildfly/EAP out of the box - Less moving parts - Potential increase in community developers: Bluntly, JPA is more widely understood and used, as opposed to JCR. I'm hoping this opens the doors to additional community members. {quote} Use JPA {quote} FWIW, I am using pure JPA, rather than Hibernate ORM. Although, the driving force behind that is mainly the JPA Criteria Query API... {quote} Then Hiberante OGM comes essentially for free. {quote} Definitely a fair point. OGM/NoSQL, Cassandra, GraphDBs, etc. could certainly be added as additional plugins, if the community wants them (and is willing to help develop them ;) {quote} so your whole argument really only boils down to a matter of runtime efficiencies (storage space & execution speed). {quote} Simply not true -- there's *a lot* more to it {quote} I strongly suggest you see Artificer as a relatively high level functional application platform for business organizations and technical organizations, rather than yet-another-lower-level-engine (of which there are hundreds and hundreds). While space and time efficiency are always important, they don't make the top 10 list of what CIOs (should, and do) consider critical ? such as reliability, manageability, scalability, security, longevity, stability, developer ease, etc. So architect with the key longterm open standards {quote} This is an absolutely vital point, and one that I focus on. Artificer needs to continue to become a powerful, out of the box application. It certainly needs to support developers and be usable as a powerful platform, but in the end, focusing on it as an *application* is where it will shine. But I'd argue that you're contradicting yourself, at least a bit. Through this tried-and-true stack, the "reliability, manageability, scalability, security, longevity, stability" increase across the board. And 80-90% of users will see the storage solution as simply an internal implementation detail. The new stack *does not change* current Artificer functionality. {quote} Instead of stripdown hotrodding, go Architectural {quote} Again, you're focusing only on the performance considerations, which are only a small piece of the decision. Realistically, we have a *long* backlog of tasks and new features to add, many of which would at least be difficult to support with JCR. A flexible architecture is definitely one area being gained... {quote} Most importantly, stick with open standards, so you let your users (like me) make our own best decision of what to put behind the standard interface. {quote} With JPA, that's what you'd be getting... {quote} and then you can have nice integrity between the 2 paradigms {quote} I have to say, I fully agree with Randall and Horia's points on https://developer.jboss.org/message/928792. Mixing JPA with JCR doesn't make much sense. {quote} IMHO, you ought to have a chat with Randall and figure out an optimal architecture. {quote} Myself, Randall, and several other committers on the Hibernate/Infinispan teams have been involved in these discussions and architecture. That should probably have been more in the open... I definitely value alternative opinions -- don't want this to sound like I'm just outright shooting you down. But, just wanted to clarify how this has shaped up. Feel free to continue the discussion! was (Author: brmeyer): [~hxp], I should clarify: this isn't *replacing* the JCR plugin. For the time being, we'll continue to support that and you'll be able to continue using it. However, this new setup will be the new *default*. I'm obviously biased (I'm a committer and one of the core devs of Hibernate ORM), but this new setup has been a long time coming and has a large amount of benefits: - Horizontal scaling: Several potential users have brought up their typical enterprise-level use cases, and they all involved primary artifacts on the order of *one million*. Once derivation kicks in, that could look more like a hundred million, maybe more. I had a lot of concerns about JCR's ability to handle queries with that much data. RDBMS + proper indexing + in-mem caching has a proven track record... - CQRS pattern: Being able to query-by-column using pure SQL, rather than pulling out entire nodes (ala JCR), has a large amount of benefits on its own (http://martinfowler.com/bliki/CQRS.html). - Full-text search: Fully-indexed, full-text search is improving in ModeShape, but it's not quite there. Using Hibernate Search and Lucene opens the doors to several new features. - BLOB storage: I've actually added a new SPI that allows both SQL BLOB or the filesystem to be used for binary storage. For most use cases, BLOBs tend to have several pros over filesystem, so at least having it as an option is beneficial. Note that this SPI would also allow for new plugins: Ceph, Gluster, etc. - Flexibility: Right out of the gate, this tremendously increases what we're able to support. Any RDBMS (that's supported by Hibernate), any Hibernate caching solution (not limited to Infinispan), etc. - Less external dependencies: nearly the entire stack is already included in Wildfly/EAP out of the box {quote} Use JPA {quote} FWIW, I am using pure JPA, rather than Hibernate ORM. Although, the driving force behind that is mainly the JPA Criteria Query API... {quote} Then Hiberante OGM comes essentially for free. {quote} Definitely a fair point. OGM/NoSQL, Cassandra, GraphDBs, etc. could certainly be added as additional plugins, if the community wants them (and is willing to help develop them ;) {quote} so your whole argument really only boils down to a matter of runtime efficiencies (storage space & execution speed). {quote} Simply not true -- there's *a lot* more to it {quote} I strongly suggest you see Artificer as a relatively high level functional application platform for business organizations and technical organizations, rather than yet-another-lower-level-engine (of which there are hundreds and hundreds). While space and time efficiency are always important, they don't make the top 10 list of what CIOs (should, and do) consider critical ? such as reliability, manageability, scalability, security, longevity, stability, developer ease, etc. So architect with the key longterm open standards {quote} This is an absolutely vital point, and one that I focus on. Artificer needs to continue to become a powerful, out of the box application. It certainly needs to support developers and be usable as a powerful platform, but in the end, focusing on it as an *application* is where it will shine. But I'd argue that you're contradicting yourself, at least a bit. Through this tried-and-true stack, the "reliability, manageability, scalability, security, longevity, stability" increase across the board. And 80-90% of users will see the storage solution as simply an internal implementation detail. {quote} Instead of stripdown hotrodding, go Architectural {quote} Again, you're focusing only on the performance considerations, which are only a small piece of the decision. Realistically, we have a *long* backlog of tasks and new features to add, many of which would at least be difficult to support with JCR. A flexible architecture is definitely one area being gained... {quote} Most importantly, stick with open standards, so you let your users (like me) make our own best decision of what to put behind the standard interface. {quote} With JPA, that's what you'd be getting... {quote} and then you can have nice integrity between the 2 paradigms {quote} I have to say, I fully agree with Randall and Horia's points on https://developer.jboss.org/message/928792. Mixing JPA with JCR doesn't make much sense. {quote} IMHO, you ought to have a chat with Randall and figure out an optimal architecture. {quote} Myself, Randall, and several other committers on the Hibernate/Infinispan teams have been involved in these discussions and architecture. That should probably have been more in the open... I definitely value alternative opinions -- don't want this to sound like I'm just outright shooting you down. But, just wanted to clarify how this has shaped up. Feel free to continue the discussion! > Switch to RDBMS, JPA (Hibernate), Hibernate Search, and Hibernate 2nd Level Cache as the default persistence solution > --------------------------------------------------------------------------------------------------------------------- > > Key: ARTIF-683 > URL: https://issues.jboss.org/browse/ARTIF-683 > Project: Artificer > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > > Artificer currently uses ModeShape + Infinispan + JDBC as its storage. Back when Artificer was a simple S-RAMP impl, JCR made a lot of sense. The S-RAMP spec is essentially a hierarchical artifact repo that maintains the node metadata and relationships between them. However, the "hierarchical" bit is overstated -- it's limited to a primary artifact and its derived artifact (ex -- primary: XSD, derived: type declarations). So, the hierarchy is at most 2 levels and could be represented by a simple relationship or one-to-one foreign key. The only time the hierarchical structure is helpful is when we look up an artifact by its UUID (due to a specific tree structure we use). But otherwise, I think it's a bit of a misnomer. > We're now extending well beyond S-RAMP. In addition to an artifact/metadata/info repo, we're trying to position the project as a more general repo for multiple projects and service information. Most importantly, the relationship requirements will expand the most. As such, I'm thinking we'd be better served by alternatives. > Note that this is essentially a read-intensive system. Writes do of course occur, but they're almost always *additions*. Nodes are rarely updated once created. Locking and isolation should be used, but can be extremely optimistic. Also note that most artifacts have files with them. That currently uses a local filesystem store through ISPN, but could certainly be NAS. > Additional fuel for the fire: many enterprise-level development shops have millions of artifacts, exponentially higher once derivation kicks in. Further, many have multiple relationships defined. > Ideas: > 1.) Switch to RDBMS, JPA (Hibernate), Hibernate Search, and Hibernate 2nd Level Cache. Although the structure originally looked JCR-specific, it may make a lot more sense as a relational DB. HSearch is a no brainer -- the full-text search capability would be vastly improved, right out of the box. And the RDBMS + in-memory-cache would be perfect for the read-intensive environment and scalability. > 2.) Graph databases: Neo4j (w/ or w/o Hibernate OGM), OrientDB, etc.. The concern here is mainly horizontal scaling and, from what I understand, their (lack of adequate) clustering support. But, it's definitely an option. > 3.) Distributed but strongly consistent database: RocksDB (a variant of LevelDB), CockroachDB. These are newer, but can (theoretically) scale larger than relational, and because they replicate data it might be more durable or at least recover faster in the event of failure. On the other hand, this may be more difficult for enterprises to adopt > 3.) Stick with MS + ISPN, but use Cassandra behind it (instead of JDBC). Arguably, this wouldn't really change things and could potentially end up worse. > 4.) Tinkerpop/Blueprints (graph API). Hawkular is using this. However, from what I've heard elsewhere, it's a horrible standard. Solutions that attempt to implement it end up in a state of twisted adaptation, resulting in performance hits. > In the end, I'd argue that #1 is the best from enterprise-level, scalability, reliability, and configurability standpoints. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed May 20 10:17:19 2015 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 20 May 2015 10:17:19 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (OVERLORD-156) Support exploded archives in modules deployment folder In-Reply-To: References: Message-ID: Gary Brown created OVERLORD-156: ----------------------------------- Summary: Support exploded archives in modules deployment folder Key: OVERLORD-156 URL: https://issues.jboss.org/browse/OVERLORD-156 Project: Overlord Issue Type: Enhancement Reporter: Gary Brown Assignee: Gary Brown Currently the archives are unexploded in the modules/.../deployments folder because the deployment code does not handle folders. Update the deployment code to support exploded archives. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed May 20 10:20:20 2015 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 20 May 2015 10:20:20 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (OVERLORD-155) UX: Overlord artwork not big enough for 1920x1080 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/OVERLORD-155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated OVERLORD-155: -------------------------------- Fix Version/s: Overlord-Commons-2.0.14.Final (was: Overlord-Commons-2.0.12.Fina) > UX: Overlord artwork not big enough for 1920x1080 > ------------------------------------------------- > > Key: OVERLORD-155 > URL: https://issues.jboss.org/browse/OVERLORD-155 > Project: Overlord > Issue Type: Bug > Affects Versions: Overlord-Commons-2.0.11.Final > Environment: firefox, chrome > Reporter: Andrej Vano > Assignee: Eric Wittmann > Priority: Trivial > Fix For: Overlord-Commons-2.0.14.Final > > > The overlord artwork is not big enough for displays with resolution 1920x1080 (I think the standard resolution at the moment). See: http://oi61.tinypic.com/2ihqwpe.jpg -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed May 20 10:20:20 2015 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 20 May 2015 10:20:20 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (OVERLORD-154) Move shared Elasticsearch functionality from rtgov into commons In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/OVERLORD-154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated OVERLORD-154: -------------------------------- Fix Version/s: Overlord-Commons-2.0.14.Final (was: Overlord-Commons-2.0.12.Fina) > Move shared Elasticsearch functionality from rtgov into commons > --------------------------------------------------------------- > > Key: OVERLORD-154 > URL: https://issues.jboss.org/browse/OVERLORD-154 > Project: Overlord > Issue Type: Task > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: Overlord-Commons-2.0.14.Final > > > Move the Elasticsearch functionality, currently used in rtgov, that is of common use to other Overlord projects. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed May 20 10:20:20 2015 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 20 May 2015 10:20:20 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (OVERLORD-148) Add support for wildfly 8 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/OVERLORD-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated OVERLORD-148: -------------------------------- Fix Version/s: Overlord-Commons-2.0.14.Final (was: Overlord-Commons-2.0.12.Fina) > Add support for wildfly 8 > ------------------------- > > Key: OVERLORD-148 > URL: https://issues.jboss.org/browse/OVERLORD-148 > Project: Overlord > Issue Type: Feature Request > Reporter: Eric Wittmann > Assignee: Gary Brown > Fix For: Overlord-Commons-2.0.14.Final > > > We need to make sure overlord-commons works and can be installed on wildfly 8. This means updating the installer and ensuring that the IDP functions properly. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed May 20 10:20:20 2015 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 20 May 2015 10:20:20 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (OVERLORD-147) Use the maven-bundle-plugin in WAR projects (overlord-commons) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/OVERLORD-147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated OVERLORD-147: -------------------------------- Fix Version/s: Overlord-Commons-2.0.14.Final (was: Overlord-Commons-2.0.12.Fina) > Use the maven-bundle-plugin in WAR projects (overlord-commons) > -------------------------------------------------------------- > > Key: OVERLORD-147 > URL: https://issues.jboss.org/browse/OVERLORD-147 > Project: Overlord > Issue Type: Task > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: Overlord-Commons-2.0.14.Final > > > Right now in our WAR projects we are using the war plugin to configure the manifest for osgi. Instead we should use the bundle plugin. > Links: > https://ops4j1.jira.com/wiki/display/paxweb/OSGi-fy+your+WAR > https://ops4j1.jira.com/wiki/display/ops4j/Getting+the+benefits+of+maven-bundle-plugin+in+other+project+types > Here is an example of using it in overlord-commons-idp: > {code} > > 4.0.0 > > org.overlord > overlord-commons > 2.0.3-SNAPSHOT > > overlord-commons-idp > war > Overlord Commons: IDP > An identity provider using PicketLink SAML. > > > > org.picketlink > picketlink-federation > > > org.picketbox > picketbox > > > org.picketlink > picketlink-federation > > > org.jboss.logging > jboss-logging > > > ${project.groupId} > overlord-commons-auth > > > ${project.groupId} > overlord-commons-auth-jboss7 > > > ${project.groupId} > overlord-commons-auth-jetty8 > > > ${project.groupId} > overlord-commons-auth-tomcat7 > > > > org.jboss.spec.javax.servlet > jboss-servlet-api_3.0_spec > provided > > > > > > org.codehaus.mojo > build-helper-maven-plugin > > > regex-property > > regex-property > > > project.version.osgi > ${project.version} > -SNAPSHOT > .Snapshot > false > > > > > > > > > > > > > > > > > > > > > > > > > > > > maven-war-plugin > > > > ${project.build.outputDirectory}/META-INF/MANIFEST.MF > > > > > org.apache.felix > maven-bundle-plugin > > > bundle-manifest > process-classes > > manifest > > > > > false --> > ${project.artifactId} > true > classes > > 2 > ${project.artifactId} > ${project.version.osgi} > /overlord-idp > /overlord-idp > org.apache.log4j,javax.servlet, javax.servlet.http,javax.security.auth.login,javax.xml.stream,javax.xml.stream.events,javax.xml.namespace,javax.xml.transform,javax.xml.transform.dom,javax.xml.transform.stream,javax.xml.parsers,javax.xml.datatype,javax.xml.crypto,javax.xml.crypto.dsig,javax.xml.bind,org.apache.karaf.jaas.boot.principal,org.eclipse.jetty.plus.jaas,org.xml.sax,org.w3c.dom,org.w3c.dom.ls,org.overlord.commons.auth.util,org.picketlink.identity.federation.core.interfaces > > .,WEB-INF/classes,WEB-INF/lib/commons-logging-${version.commons-logging}.jar,WEB-INF/lib/jboss-logging-${version.org.jboss.logging}.jar,WEB-INF/lib/jbossxacml-2.0.8.Final.jar,WEB-INF/lib/picketbox-${picketbox.version}.jar,WEB-INF/lib/picketlink-common-${picketlink.version}.jar,WEB-INF/lib/picketlink-config-${picketlink.version}.jar,WEB-INF/lib/picketlink-federation-${picketlink.version}.jar,WEB-INF/lib/picketlink-idm-api-${picketlink.version}.jar,WEB-INF/lib/picketlink-idm-impl-${picketlink.version}.jar,WEB-INF/lib/xmlsec-1.5.1.jar > > > > > > > > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed May 20 11:03:19 2015 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 20 May 2015 11:03:19 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (OVERLORD-156) Support exploded archives in modules deployment folder In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/OVERLORD-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated OVERLORD-156: -------------------------------- Fix Version/s: Overlord-Commons-2.0.14.Final Git Pull Request: https://github.com/Governance/overlord-commons/pull/122 > Support exploded archives in modules deployment folder > ------------------------------------------------------ > > Key: OVERLORD-156 > URL: https://issues.jboss.org/browse/OVERLORD-156 > Project: Overlord > Issue Type: Enhancement > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: Overlord-Commons-2.0.14.Final > > > Currently the archives are unexploded in the modules/.../deployments folder because the deployment code does not handle folders. Update the deployment code to support exploded archives. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed May 20 11:03:19 2015 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 20 May 2015 11:03:19 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (OVERLORD-156) Support exploded archives in modules deployment folder In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/OVERLORD-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved OVERLORD-156. --------------------------------- Resolution: Done > Support exploded archives in modules deployment folder > ------------------------------------------------------ > > Key: OVERLORD-156 > URL: https://issues.jboss.org/browse/OVERLORD-156 > Project: Overlord > Issue Type: Enhancement > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: Overlord-Commons-2.0.14.Final > > > Currently the archives are unexploded in the modules/.../deployments folder because the deployment code does not handle folders. Update the deployment code to support exploded archives. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu May 21 09:44:20 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 21 May 2015 09:44:20 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-675) Define new "service" model In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-675: ------------------------------ Description: Define a new, generic model to better encapsulate "services", discovery, and re-use. Ideas (from various sources): - Provides a catalog of information, what services exist and are available for use - Presents the condition of the service lifecycle is eg. Implemented, testing, advised against, etc. - Provides information about the version of the services - Allows you to record and retrieve multiple versions of the same service - Allows you to dynamically refer to the latest version of the service - Allows dynamically at runtime to search and select end-point chosen service - Collects information who and what services are used - Provides information that services are repeatedly used and which are not - Determining the impact of changes the services to existing dependent services - Providing information to consumers of the services about ongoing or planned changes to of the services - Differentiate between was: Define a new, generic model to better encapsulate "services", discovery, and re-use. Ideas (from various sources): - Provides a catalog of information, what services exist and are available for use - Presents the condition of the service lifecycle is eg. Implemented, testing, advised against, etc. - Provides information about the version of the services - Allows you to record and retrieve multiple versions of the same service - Allows you to dynamically refer to the latest version of the service - Allows dynamically at runtime to search and select end-point chosen service - Collects information who and what services are used - Provides information that services are repeatedly used and which are not - Determining the impact of changes the services to existing dependent services - Providing information to consumers of the services about ongoing or planned changes to of the services > Define new "service" model > -------------------------- > > Key: ARTIF-675 > URL: https://issues.jboss.org/browse/ARTIF-675 > Project: Artificer > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > > Define a new, generic model to better encapsulate "services", discovery, and re-use. > Ideas (from various sources): > - Provides a catalog of information, what services exist and are available for use > - Presents the condition of the service lifecycle is eg. Implemented, testing, advised against, etc. > - Provides information about the version of the services > - Allows you to record and retrieve multiple versions of the same service > - Allows you to dynamically refer to the latest version of the service > - Allows dynamically at runtime to search and select end-point chosen service > - Collects information who and what services are used > - Provides information that services are repeatedly used and which are not > - Determining the impact of changes the services to existing dependent services > - Providing information to consumers of the services about ongoing or planned changes to of the services > - Differentiate between -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu May 21 09:46:19 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 21 May 2015 09:46:19 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-675) Define new "service" model In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-675: ------------------------------ Description: Define a new, generic model to better encapsulate "services", discovery, and re-use. Ideas (from various sources): - Provides a catalog of information, what services exist and are available for use - Presents the condition of the service lifecycle is eg. Implemented, testing, advised against, etc. - Provides information about the version of the services - Allows you to record and retrieve multiple versions of the same service - Allows you to dynamically refer to the latest version of the service - Allows dynamically at runtime to search and select end-point chosen service - Collects information who and what services are used - Provides information that services are repeatedly used and which are not - Determining the impact of changes the services to existing dependent services - Providing information to consumers of the services about ongoing or planned changes to of the services - Identify the environments (OS, app server, etc.) supported by the artifact - Differentiate between front and back end artifacts was: Define a new, generic model to better encapsulate "services", discovery, and re-use. Ideas (from various sources): - Provides a catalog of information, what services exist and are available for use - Presents the condition of the service lifecycle is eg. Implemented, testing, advised against, etc. - Provides information about the version of the services - Allows you to record and retrieve multiple versions of the same service - Allows you to dynamically refer to the latest version of the service - Allows dynamically at runtime to search and select end-point chosen service - Collects information who and what services are used - Provides information that services are repeatedly used and which are not - Determining the impact of changes the services to existing dependent services - Providing information to consumers of the services about ongoing or planned changes to of the services - Differentiate between > Define new "service" model > -------------------------- > > Key: ARTIF-675 > URL: https://issues.jboss.org/browse/ARTIF-675 > Project: Artificer > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > > Define a new, generic model to better encapsulate "services", discovery, and re-use. > Ideas (from various sources): > - Provides a catalog of information, what services exist and are available for use > - Presents the condition of the service lifecycle is eg. Implemented, testing, advised against, etc. > - Provides information about the version of the services > - Allows you to record and retrieve multiple versions of the same service > - Allows you to dynamically refer to the latest version of the service > - Allows dynamically at runtime to search and select end-point chosen service > - Collects information who and what services are used > - Provides information that services are repeatedly used and which are not > - Determining the impact of changes the services to existing dependent services > - Providing information to consumers of the services about ongoing or planned changes to of the services > - Identify the environments (OS, app server, etc.) supported by the artifact > - Differentiate between front and back end artifacts -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu May 21 09:52:19 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 21 May 2015 09:52:19 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-686) HTML/CSS/JS artifacts In-Reply-To: References: Message-ID: Brett Meyer created ARTIF-686: --------------------------------- Summary: HTML/CSS/JS artifacts Key: ARTIF-686 URL: https://issues.jboss.org/browse/ARTIF-686 Project: Artificer Issue Type: Feature Request Reporter: Brett Meyer Assignee: Brett Meyer If an HTML/JSP/etc, CSS, or JS file is uploaded (or discovered during expansion), support with a new ArtifactBuilder and new derivation. Powerful examples: 1.) Which HTML files import the given CSS 2.) Which HTML *elements* utilize the given CSS *class* -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu May 21 09:53:22 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 21 May 2015 09:53:22 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-675) Define new "service" model In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-675: ------------------------------ Description: Define a new, generic model to better encapsulate "services", discovery, and re-use. Arguably, some of this should probably be added to the core, base model as well. Ideas (from various sources): - Provides a catalog of information, what services exist and are available for use - Presents the condition of the service lifecycle is eg. Implemented, testing, advised against, etc. - Provides information about the version of the services - Allows you to record and retrieve multiple versions of the same service - Allows you to dynamically refer to the latest version of the service - Allows dynamically at runtime to search and select end-point chosen service - Collects information who and what services are used - Provides information that services are repeatedly used and which are not - Determining the impact of changes the services to existing dependent services - Providing information to consumers of the services about ongoing or planned changes to of the services - Identify the environments (OS, app server, etc.) supported by the artifact - Differentiate between front and back end artifacts - Security: what version of SSL is used, etc. (extremely valuable for security audits) was: Define a new, generic model to better encapsulate "services", discovery, and re-use. Ideas (from various sources): - Provides a catalog of information, what services exist and are available for use - Presents the condition of the service lifecycle is eg. Implemented, testing, advised against, etc. - Provides information about the version of the services - Allows you to record and retrieve multiple versions of the same service - Allows you to dynamically refer to the latest version of the service - Allows dynamically at runtime to search and select end-point chosen service - Collects information who and what services are used - Provides information that services are repeatedly used and which are not - Determining the impact of changes the services to existing dependent services - Providing information to consumers of the services about ongoing or planned changes to of the services - Identify the environments (OS, app server, etc.) supported by the artifact - Differentiate between front and back end artifacts > Define new "service" model > -------------------------- > > Key: ARTIF-675 > URL: https://issues.jboss.org/browse/ARTIF-675 > Project: Artificer > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > > Define a new, generic model to better encapsulate "services", discovery, and re-use. Arguably, some of this should probably be added to the core, base model as well. > Ideas (from various sources): > - Provides a catalog of information, what services exist and are available for use > - Presents the condition of the service lifecycle is eg. Implemented, testing, advised against, etc. > - Provides information about the version of the services > - Allows you to record and retrieve multiple versions of the same service > - Allows you to dynamically refer to the latest version of the service > - Allows dynamically at runtime to search and select end-point chosen service > - Collects information who and what services are used > - Provides information that services are repeatedly used and which are not > - Determining the impact of changes the services to existing dependent services > - Providing information to consumers of the services about ongoing or planned changes to of the services > - Identify the environments (OS, app server, etc.) supported by the artifact > - Differentiate between front and back end artifacts > - Security: what version of SSL is used, etc. (extremely valuable for security audits) -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu May 21 09:56:19 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 21 May 2015 09:56:19 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-687) Provide a way to migrate artifacts from an existing Maven repo In-Reply-To: References: Message-ID: Brett Meyer created ARTIF-687: --------------------------------- Summary: Provide a way to migrate artifacts from an existing Maven repo Key: ARTIF-687 URL: https://issues.jboss.org/browse/ARTIF-687 Project: Artificer Issue Type: Feature Request Reporter: Brett Meyer Assignee: Brett Meyer It would be really helpful for new users to have a way to migrate artifacts from an existing Maven repo. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue May 26 10:43:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 26 May 2015 10:43:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-688) Create an ArtifactBuilder for Swagger files In-Reply-To: References: Message-ID: Brett Meyer created ARTIF-688: --------------------------------- Summary: Create an ArtifactBuilder for Swagger files Key: ARTIF-688 URL: https://issues.jboss.org/browse/ARTIF-688 Project: Artificer Issue Type: Feature Request Reporter: Brett Meyer Assignee: Brett Meyer An an artifact type and deriver for Swagger REST API files -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue May 26 10:44:03 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 26 May 2015 10:44:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-404) Create an ArtifactBuilder for WADL files In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-404: ------------------------------ Summary: Create an ArtifactBuilder for WADL files (was: Create a Deriver for WADL files) > Create an ArtifactBuilder for WADL files > ---------------------------------------- > > Key: ARTIF-404 > URL: https://issues.jboss.org/browse/ARTIF-404 > Project: Artificer > Issue Type: Feature Request > Components: Core > Reporter: Eric Wittmann > Assignee: Brett Meyer > > We currently have Derivers for WSDL and related SOA artifact types, but it would be nice to have a Deriver for WADL files. > This feature request initiated from: > https://community.jboss.org/message/869323 -- This message was sent by Atlassian JIRA (v6.3.15#6346)