[JBoss JIRA] (JBIDE-15135) Attach metadata during assembly instead of publish time
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15135?page=com.atlassian.jira.plugi... ]
Mickael Istria commented on JBIDE-15135:
----------------------------------------
Even easier would be to put build metadata directly in p2 repo (or vice-versa) so we're publication-agnostic (can publish site with any mechanism and this would still work).
> Attach metadata during assembly instead of publish time
> -------------------------------------------------------
>
> Key: JBIDE-15135
> URL: https://issues.jboss.org/browse/JBIDE-15135
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: build
> Reporter: Mickael Istria
> Fix For: 4.2.x
>
>
> In order to make it easier to deal with Nexus and to have an homogeneous way to access build metadata (commit id), it would be interesting to move creation of metadata at assembly time (same time as when we create index and so on), and put it directly into the site.
> Then whether we use Nexus or a home-made publication, we are sure that we can access metadata whenever we can access the binaries.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (JBIDE-3628) Plugins should be .jar's not directories for efficiency sake
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-3628?page=com.atlassian.jira.plugin... ]
Mickael Istria commented on JBIDE-3628:
---------------------------------------
While hibernate.libs , xpcom or xulrunner contains some resources (jar, .o or .dll) that may need to be directly accessible in filesystem, there is IMO no obvious reason for other bundles to be unpacked.
> Plugins should be .jar's not directories for efficiency sake
> ------------------------------------------------------------
>
> Key: JBIDE-3628
> URL: https://issues.jboss.org/browse/JBIDE-3628
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: build, common/jst/core, freemarker, hibernate, jsf, visual-page-editor-core
> Reporter: Max Rydahl Andersen
> Assignee: Denis Golovin
> Priority: Critical
> Fix For: 4.2.0.Alpha2
>
> Attachments: exception.log
>
>
> 65 of our plugins are bundled exploded instead of a .jar
> Some are probably just mistakes and can easily be packed others are because of legacy code assuming it can access the files directly and even store data in the plugins - that should be fixed.
> What should be fixed:
> 1. The way how plug-ins use images in plugin.xml, in java code and in .meta xmodel files
> 2. Plug-ins that loads resources should be aware that they are in jar now (VPE should be able to load templates from plugin jar files)
> 3. Some plug-ins contain resources registered in XML catalog
> 4. common.projecttemplates contains resources that is used as template for new projects
> 5. Help content that is stored in zip files should be unpacked
> 6. TBD
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (JBDS-631) Reverse Step filtering in Dev. studio
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBDS-631?page=com.atlassian.jira.plugin.s... ]
Mickael Istria commented on JBDS-631:
-------------------------------------
[~maxandersen] I don't understand the context of this issue? Should it be moved to a JBoss Tools component, or upstream to Eclipse?
> Reverse Step filtering in Dev. studio
> -------------------------------------
>
> Key: JBDS-631
> URL: https://issues.jboss.org/browse/JBDS-631
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: 3rd-party-dependencies
> Affects Versions: 2.0.0.cr2
> Reporter: Shaun Appleton
> Fix For: LATER
>
>
> Would it be possible to have an option to reverse the step filtering? Ie. to have the filters be inclusion instead of exclusion filters?
> I am unsure about the normal case in enterprise development but in our case at least all packages are prefixed dk.telenor.*
> It would be very useful if it where possible to specify just one debugging step filter (ie. include dk.telenor packages).
> Workaround is to add all possible packages, select all then un-select the ones you are interested in.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (JBDS-1609) Installer should check system prerequisites and warn user if they are not fullfilled
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBDS-1609?page=com.atlassian.jira.plugin.... ]
Mickael Istria commented on JBDS-1609:
--------------------------------------
Reducing priority because it seems to me we didn't have many complaints on this topic. Not sure it's worth the effort.
> Installer should check system prerequisites and warn user if they are not fullfilled
> ------------------------------------------------------------------------------------
>
> Key: JBDS-1609
> URL: https://issues.jboss.org/browse/JBDS-1609
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: installer
> Affects Versions: 4.0.0.GA
> Reporter: Jiri Peterka
> Assignee: Denis Golovin
> Priority: Minor
> Fix For: 8.0.0.Alpha2
>
>
> To prevent insufficient machine parameters or setting installer should do basic check for some parameters like:
> - memory amount
> - maximum open file limit
> - maximum thread count limit
> - internet connection
> - others reasonable criteria should be added here
> If these criteria aren't met, installer should display add warning page before further installation saying that requirements aren't satisfied and tools may not work properly. Reason for this is that sometimes JBDS is used in very strict environment (typically training rooms, universities, etc where many system resources are limited or blocked) but user isn't warned and after install user can see after that lots of runtime errors and got bad feeling about the tool. This should be avoided and user should be at least warn that he is running JBDS in inappropriate environment.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months