A bit late but I agree 100% with the idea of having the admin-ui as a separate project. Frontend and backend should never be the same piece, specially when nowadays we have so many good frameworks available for web.

On 2 February 2017 at 17:11, Luke Holmquist <lholmqui@redhat.com> wrote:


On Thu, Feb 2, 2017 at 10:58 AM, Leonardo Rossetti <lrossett@redhat.com> wrote:
WAR/JAR file would be for UPS deployment/build only, the repository itself would only contain frontend related files (being published in NPM as well).

Did a quick search on NPM and found this package[1], is this the one?

that's not the one.   i do believe that is being used though in your new node-test-suite thing 

On Thu, Feb 2, 2017 at 1:32 PM, Sebastien Blanc <scm.blanc@gmail.com> wrote:


On Thu, Feb 2, 2017 at 3:04 PM, Matthias Wessendorf <matzew@apache.org> wrote:


On Thu, Feb 2, 2017 at 2:50 PM, Luke Holmquist <lholmqui@redhat.com> wrote:
I believe the UI was in its own repo during the first iteration(when it was ember :))


yep, and it was a PITA to integrate the pure JS files
 

If we want to attract contributors from the JS community,  then making it a WAR is not really a great idea,   

sure, but... how useful is the UI outside of the context of push? and, bundling w/ push... perhaps we release it as NPM, and include that, somehow, into a WAR?
I think we already publish it as NPM module for the integration with RHMAP.  
I see no other option for our deployment model
 


On Thu, Feb 2, 2017 at 8:01 AM, Matthias Wessendorf <matzew@apache.org> wrote:
separate repo, not sure
separate WAR file, I think at some point I want to have a bunch of different WAR files:
* sender_API.war
* registration_API.war
* ui.war
core.jar (EJB w/ the messaging, as core)

but, that's a bit in the future... we have some Swarm related JIRAs for that 

On Thu, Feb 2, 2017 at 1:31 PM, Leonardo Rossetti <lrossett@redhat.com> wrote:
Hello,

Currently we have the UPS admin UI embedded into aerogear-unifiedpush-server project/repository.

Could the admin-ui be a separated project (repository) with its own war file?

While it may increase release process complexity (a new project dependency), I think it brings some benefits to the table, such as having a development cycle of this own, easier to write automated tests and easier to attract contributors from the javascript community (since we would be using common javascript tools to build it).

WDYT?


_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
Jose Miguel Gallas Olmedo
Associate QE at Mobile Team, Red Hat
+34 618 488 633