[ 
https://issues.apache.org/jira/browse/PIO-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15716121#comment-15716121
 ] 

ASF GitHub Bot commented on PIO-47:
-----------------------------------

Github user pferrel commented on the issue:

    https://github.com/apache/incubator-predictionio/pull/328
  
    ok, this looks like a good step
    
    @dszeto we would not do `pio build` we would do `sbt build` in the 
directory that has the template and this is fine IMO. The confusion users have 
is over pio commands.
    
    BTW @chanlee514 @dszeto Are we thinking of a new command, something like 
`pio register` that would add metadata to the metastore? This would need to be 
run every time the engine.json changed for instance? It would also do not 
compile? Is there an alternative? What state does this leave us in? After the 
push, what action create binary (I assume `pio build`) what action adds 
metadata to the metastore (I assume `pio build`) So this is only about changing 
the instance id and getting rid of manifest, right?
    
    If so I'm totally cool with this, a good step I agree. I guess I'm using 
this PR as a forum for discussion and will move it to @dev 


> Remove engine manifest for stateless build
> ------------------------------------------
>
>                 Key: PIO-47
>                 URL: https://issues.apache.org/jira/browse/PIO-47
>             Project: PredictionIO
>          Issue Type: New Feature
>            Reporter: Chan
>
> As discussed in the dev mailing list, removing engine manifest would be the 
> first step in improving the workflow towards a more modular design. 
> - Remove manifest.json completely. `pio build` will be stateless, and will 
> not write anything to the database. This will make it easier to compile/build 
> on PaaS platforms such as Heroku. Later, we can remove `pio build` command 
> entirely, so that PIO is independent of the build tool (sbt).
> - An immediate major disadvantage would be not being able to run pio commands 
> outside of the engine directory. This can be resolved in the next step of 
> creating a general metadata registry.
> - Meanwhile, we can use engineFactory as *engineId* , and SHA-1 hash of 
> engine filepath as *engineVersion* (as before). We can improve this when 
> designing a metadata registry, 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to